Event Logging (Windows Installer)

Windows Events provides a standard, centralized way for applications (and the operating system) to record important software and hardware events. The event-logging service stores events from various sources in a single collection called an event log. Prior to WindowsВ Vista, you would use either Event Tracing for Windows (ETW) or Event Logging to log events. WindowsВ Vista introduced a new eventing model that unifies both ETW and the Windows Event Log API.

The installer also writes entries into the event log. These record events such as following:

• Success or failure of the installation; removal or repair of a product.
• Errors that occur during product configuration.
• Detection of corrupted configuration data.

If a large amount of information is written, the Event Log file can become full and the installer displays the message, «The Application log file is full.»

The installer may write the following entries in the event log. All event log messages have a unique event ID. All general errors authored in the Error table that are returned for an installation that fails are logged in the Application Event Log with a message ID equal to the Error + 10,000. For example, the error number in the Error table for an installation completed successfully is 1707. The successful installation is logged in the Application Event Log with a message ID of 11707 (1707 + 10,000).

For information about how to enable verbose logging on a user’s computer when troubleshooting deployment, see Windows Installer Best Practices.

How to: Log Information About Services

By default, all Windows Service projects have the ability to interact with the Application event log and write information and exceptions to it. You use the AutoLog property to indicate whether you want this functionality in your application. By default, logging is turned on for any service you create with the Windows Service project template. You can use a static form of the EventLog class to write service information to a log without having to create an instance of an EventLog component or manually register a source.

The installer for your service automatically registers each service in your project as a valid source of events with the Application log on the computer where the service is installed, when logging is turned on. The service logs information each time the service is started, stopped, paused, resumed, installed, or uninstalled. It also logs any failures that occur. You do not need to write any code to write entries to the log when using the default behavior; the service handles this for you automatically.

If you want to write to an event log other than the Application log, you must set the AutoLog property to false , create your own custom event log within your services code, and register your service as a valid source of entries for that log. You must then write code to record entries to the log whenever an action you’re interested in occurs.

If you use a custom event log and configure your service application to write to it, you must not attempt to access the event log before setting the service’s ServiceName property in your code. The event log needs this property’s value to register your service as a valid source of events.

To enable default event logging for your service

Set the AutoLog property for your component to true .

By default, this property is set to true . You do not need to set this explicitly unless you are building more complex processing, such as evaluating a condition and then setting the AutoLog property based on the result of that condition.

To disable event logging for your service

Set the AutoLog property for your component to false .

To set up logging to a custom log

Set the AutoLog property to false .

You must set AutoLog to false in order to use a custom log.

Set up an instance of an EventLog component in your Windows Service application.

Create a custom log by calling the CreateEventSource method and specifying the source string and the name of the log file you want to create.

Set the Source property on the EventLog component instance to the source string you created in step 3.

Write your entries by accessing the WriteEntry method on the EventLog component instance.

The following code shows how to set up logging to a custom log.

In this code example, an instance of an EventLog component is named eventLog1 ( EventLog1 in Visual Basic). If you created an instance with another name in step 2, change the code accordingly.

Просмотр журнала приложений Windows (Windows 10) View the Windows application log (Windows 10)

Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions) Применимо к: Applies to: SQL Server SQL Server (все поддерживаемые версии) SQL Server SQL Server (all supported versions)

Когда для SQL Server SQL Server настроено использование журнала приложений Windows, каждый сеанс SQL Server SQL Server записывает новые события в этот журнал. SQL Server SQL Server is configured to use the Windows application log, each SQL Server SQL Server session writes new events to that log. В отличие от журнала ошибок SQL Server SQL Server , новый журнал приложений не создается заново каждый раз при запуске экземпляра SQL Server SQL Server . Unlike the SQL Server SQL Server error log, a new application log is not created each time you start an instance of SQL Server SQL Server .

Просмотр журнала приложений Windows View the Windows application log

На панели поиска введите средство просмотра событий, а затем выберите классическое приложение Просмотр событий. On the Search bar, type Event Viewer, and then select the Event Viewer desktop app.

В средстве просмотра событий откройте журналы приложений и служб. In Event Viewer, open the Applications and Services Logs.

События SQL Server SQL Server идентифицируются записью MSSQLSERVER в столбце Источник (именованные экземпляры обозначаются как MSSQL$ ). SQL Server SQL Server events are identified by the entry MSSQLSERVER (named instances are identified with MSSQL$ ) in the Source column. События агента SQL Server идентифицируются записью SQLSERVERAGENT (для именованных экземпляров сервера SQL Server SQL Server события агента SQL Server SQL Server идентифицируются при помощи SQLAgent$ ). SQL Server Agent events are identified by the entry SQLSERVERAGENT (for named instances of SQL Server SQL Server , SQL Server SQL Server Agent events are identified with SQLAgent$ ). События службы Microsoft Search идентифицируются записью Microsoft Search. Microsoft Search service events are identified by the entry Microsoft Search.

Чтобы просмотреть журнал с другого компьютера, щелкните правой кнопкой мыши элемент Просмотр событий (локальных) . To view the log of a different computer, right-click Event Viewer (local). Выберите пункт Подключение к другому компьютеру и заполните поля в диалоговом окне Выбор компьютера. Select Connect to another computer, and fill in the fields to complete the Select Computer dialog box.

Чтобы отображались только события SQL Server SQL Server , в меню Вид выберите пункт Фильтр. Optionally, to display only SQL Server SQL Server events, on the View menu, select Filter. В списке Источник событий выберите MSSQLSERVER. In the Event source list, select MSSQLSERVER. Чтобы просмотреть только события агента SQL Server SQL Server , в списке Источник события вместо этого выберите SQLSERVERAGENT . To view only SQL Server SQL Server Agent events, instead select SQLSERVERAGENT in the Event source list.

Чтобы просмотреть дополнительные сведения о событии, дважды щелкните событие. To view more information about an event, double-click the event.

Introduction to Windows Service Applications

Microsoft Windows services, formerly known as NT services, enable you to create long-running executable applications that run in their own Windows sessions. These services can be automatically started when the computer boots, can be paused and restarted, and do not show any user interface. These features make services ideal for use on a server or whenever you need long-running functionality that does not interfere with other users who are working on the same computer. You can also run services in the security context of a specific user account that is different from the logged-on user or the default computer account. For more information about services and Windows sessions, see the Windows SDK documentation.

You can easily create services by creating an application that is installed as a service. For example, suppose you want to monitor performance counter data and react to threshold values. You could write a Windows Service application that listens to the performance counter data, deploy the application, and begin collecting and analyzing data.

You create your service as a Microsoft Visual Studio project, defining code within it that controls what commands can be sent to the service and what actions should be taken when those commands are received. Commands that can be sent to a service include starting, pausing, resuming, and stopping the service; you can also execute custom commands.

After you create and build the application, you can install it by running the command-line utility InstallUtil.exe and passing the path to the service’s executable file. You can then use the Services Control Manager to start, stop, pause, resume, and configure your service. You can also accomplish many of these same tasks in the Services node in Server Explorer or by using the ServiceController class.

Service Applications vs. Other Visual Studio Applications

Service applications function differently from many other project types in several ways:

The compiled executable file that a service application project creates must be installed on the server before the project can function in a meaningful way. You cannot debug or run a service application by pressing F5 or F11; you cannot immediately run a service or step into its code. Instead, you must install and start your service, and then attach a debugger to the service’s process. For more information, see How to: Debug Windows Service Applications.

Unlike some types of projects, you must create installation components for service applications. The installation components install and register the service on the server and create an entry for your service with the Windows Services Control Manager. For more information, see How to: Add Installers to Your Service Application.

The Main method for your service application must issue the Run command for the services your project contains. The Run method loads the services into the Services Control Manager on the appropriate server. If you use the Windows Services project template, this method is written for you automatically. Note that loading a service is not the same thing as starting the service. See «Service Lifetime» below for more information.

Windows Service applications run in a different window station than the interactive station of the logged-on user. A window station is a secure object that contains a Clipboard, a set of global atoms, and a group of desktop objects. Because the station of the Windows service is not an interactive station, dialog boxes raised from within a Windows service application will not be seen and may cause your program to stop responding. Similarly, error messages should be logged in the Windows event log rather than raised in the user interface.

The Windows service classes supported by the .NET Framework do not support interaction with interactive stations, that is, the logged-on user. The .NET Framework also does not include classes that represent stations and desktops. If your Windows service must interact with other stations, you will need to access the unmanaged Windows API. For more information, see the Windows SDK documentation.

The interaction of the Windows service with the user or other stations must be carefully designed to include scenarios such as there being no logged on user, or the user having an unexpected set of desktop objects. In some cases, it may be more appropriate to write a Windows application that runs under the control of the user.

Windows service applications run in their own security context and are started before the user logs into the Windows computer on which they are installed. You should plan carefully what user account to run the service within; a service running under the system account has more permissions and privileges than a user account.

Service Lifetime

A service goes through several internal states in its lifetime. First, the service is installed onto the system on which it will run. This process executes the installers for the service project and loads the service into the Services Control Manager for that computer. The Services Control Manager is the central utility provided by Windows to administer services.

After the service has been loaded, it must be started. Starting the service allows it to begin functioning. You can start a service from the Services Control Manager, from Server Explorer, or from code by calling the Start method. The Start method passes processing to the application’s OnStart method and processes any code you have defined there.

A running service can exist in this state indefinitely until it is either stopped or paused or until the computer shuts down. A service can exist in one of three basic states: Running, Paused, or Stopped. The service can also report the state of a pending command: ContinuePending, PausePending, StartPending, or StopPending. These statuses indicate that a command has been issued, such as a command to pause a running service, but has not been carried out yet. You can query the Status to determine what state a service is in, or use the WaitForStatus to carry out an action when any of these states occurs.

You can pause, stop, or resume a service from the Services Control Manager, from Server Explorer, or by calling methods in code. Each of these actions can call an associated procedure in the service (OnStop, OnPause, or OnContinue), in which you can define additional processing to be performed when the service changes state.

Types of Services

There are two types of services you can create in Visual Studio using the .NET Framework. Services that are the only service in a process are assigned the type Win32OwnProcess. Services that share a process with another service are assigned the type Win32ShareProcess. You can retrieve the service type by querying the ServiceType property.

You might occasionally see other service types if you query existing services that were not created in Visual Studio. For more information on these, see the ServiceType.

Services and the ServiceController Component

The ServiceController component is used to connect to an installed service and manipulate its state; using a ServiceController component, you can start and stop a service, pause and continue its functioning, and send custom commands to a service. However, you do not need to use a ServiceController component when you create a service application. In fact, in most cases your ServiceController component should exist in a separate application from the Windows service application that defines your service.

For more information, see ServiceController.

Requirements

Services must be created in a Windows Service application project or another .NET Framework–enabled project that creates an .exe file when built and inherits from the ServiceBase class.

Projects containing Windows services must have installation components for the project and its services. This can be easily accomplished from the Properties window. For more information, see How to: Add Installers to Your Service Application.