Diagnostic Provider for SERVICES.EXE

Something new for SERVICES.EXE in Windows Vista is an event provider that writes analytic events:

This provider is described in an instrumentation manifest, which Microsoft supplies as an <instrumentation> block within the manifest that represents SERVICES.EXE as an assembly. Refer to the separate note about SERVICES Versions for the name and location. The instrumentation manifest is also compiled into the SERVICES resources, as WEVT_TEMPLATE.

Default Channel

The registry is installed with the Microsoft-Windows-Services provider already configured as a publisher to the following log, which the instrumentation manifest specifies as the default channel:

The name given for the session is how it appears in the Reliability and Performance Monitor among the Event Trace Sessions. The channel is the name needed for WEVTUTIL. The Event Viewer lists the session among the Applications and Services Logs, as the Diagnostic channel of the Microsoft Windows Services Performance Diagnostic Provider.

Permissions

As with other direct channels (i.e., for analytic and debug events), this one is not ordinarily enabled. Unlike most others, this one is somewhat difficult to enable. Indeed, the ordinary configuration does not permit this log to be enabled through the Event Viewer without causing an error to be reported to the System log. The event ID is 30, with Eventlog as the source:

The event logging service encountered an error (5) while enabling publisher {0063715B-EEDA-4007-9429-AD526F62696E} to channel Microsoft-Windows-Services/Diagnostic. This doesn't affect operation of the channel, but does affect the ability for the publisher to raise events to the channel. One common cause for this error is that Provider is using ETW Provider Security and has not granted enable permissions to the Eventlog service entity.

The text, though arguably cryptic, is correct. The Microsoft-Windows-Services provider is one of relatively few for which the ordinary configuration of Windows specifies a security descriptor. Only the SYSTEM account and the Administrators group are permitted any access. Though the Event Viewer runs with administrative privilege, the system call that would enable the Microsoft-Windows-Services provider for the Microsoft-Windows-Services/Diagnostic log is actually made by the Eventlog service, executing as WEVTSVC.DLL in a SVCHOST.EXE process that runs from the LOCAL SERVICE account. To enable this log without an error, you must first add suitable permissions for the LOCAL SERVICE account.

Permissions for the Microsoft-Windows-Services provider are set through the registry:

The binary data is the security descriptor for the provider. You could edit this by hand, but there actually is user-interface support, albeit in a round-about way. Though Windows does not come with a program for operating on security for arbitrary providers and sessions, the Reliability and Performance Monitor allows for working with security for providers and sessions that are started already (whether or not enabled) or are registered to start automatically when Windows next starts. The trick, then, begins with getting the Reliabilty and Performance Monitor to list the Microsoft-Windows-Services provider.

Start the Reliability and Performance Monitor. Expand the tree on the left to expose Event Trace Sessions. Click on that and then start creating a Data Collector Set. Give it some name such as Temporary, and elect to create manually. Ask to Add a provider and when the large list of known providers appears, select Microsoft-Windows-Services and then Finish. Now get Properties for your new data collector set. The Trace Providers tab will allow you to set security for the Microsoft-Windows-Services provider through a standard user interface. When done, click OK and then delete the Temporary data collector set. Thereafter, you can enable the Microsoft-Windows-Services/Diagnostic log through the Event Viewer without causing an error to appear in the System log.

WDI Context Provider

Microsoft-Windows-Services is a context provider for the Windows Diagnostic Infrastructure (WDI). This means that a selection of the possible events gets written to the DiagLog and WdiContextLog sessions. Both are configured in the registry as auto-loggers, and are ordinarily configured to start automatically. The DiagLog is a real-time log, but the WdiContextLog streams to a file, and the backups from previous Windows sessions can be loaded into the Event Viewer for inspection.

Events for this log are selected both by the usual mechanism, of level and keyword, and also by the WDI mechanism of enabling the provider only during an applicable scenario. Since all the possible events from Microsoft-Windows-Services happen to have the same level and keyword, only the scenarios matter. There are four applicable scenarios:

Between the start and end events from these other event providers, the kernel enables Microsoft-Windows-Services so that all events from the Microsoft-Windows-Services provider are logged to WDI.

Events

There are presently just a handful of possible event IDs, but the facility is surely meant to expand. Unfortunately, none of the event definitions in the manifest supply formatted text, e.g., through a message attribute, and so the Event Viewer falls back to the following distinctly unhelpful description:

The description for Event ID id from source Microsoft-Windows-Services cannot be found. Either the component that raises the event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.

Still, the manifest is useful because it labels the event data. All these events have win:Informational (4) as the level and 0x8000000000000000 as the keyword. The manifest has no plain-language representation of this keyword.