The Service Control Manager Eventlog Provider

Events that SERVICES.EXE writes to the System log are most easily identified in the Event Viewer as the ones whose source is listed as Service Control Manager Eventlog Provider. However, that is just a localised friendly name, as picked up from a manifest. The formal name of the event provider itself is just Service Control Manager. This is what’s stored in the registry. It is what you will see on the Details tab for an event in the Event Viewer, and it is the name you need if controlling this provider through such tools as WEVTUTIL or the Reliability and Performance Monitor.

Events from this provider get to the System log in the Event Viewer because Windows is set up so that the registry has this provider already configured as a publisher to the Eventlog-System session.

It may be as well to explain here that when SERVICES fires these events to the System log, it is not a manifest-based provider despite coming with an instrumentation manifest, nor is it exactly what the documentation refers to as a classic provider. The way it fires events is a little exotic. Early versions are straightforward users of the functions that Microsoft documents for Event Logging, such as RegisterEventSource and ReportEvent, but there was a significant recoding for Windows XP. SERVICES is nowadays a Windows Management Instrumentation (WMI) event provider, and specifically a decoupled non-COM provider. The non-COM aspect is undocumented. Indeed, the page Provider Hosting and Security from the Windows SDK states explicitly that the Decoupled:Noncom hosting model is “for internal use only” and is “not supported”. SERVICES is one of its very few users. It relies on undocumented functions such as WmiEventSourceConnect, WmiCreateObjectWithFormat and WmiSetAndCommitObject that are implemented in NCOBJAPI.DLL.

The WMI provider in SERVICES calls itself the SCM Event Provider, in the root\cimv2 namespace. Aside from using the non-COM API, delivery into the event log is as straightforward as for any WMI event provider. Each possible event is a managed object and is represented by a WMI class. Parameters that can be passed with the event are represented as members of the class. The name of the class and the names of the parameters are hard-coded in SERVICES, which registers them at run-time with WMI. The mapping of these managed objects to Windows events depends on matching their names with definitions that have been compiled into the WMI repository from a source file named SCM.MOF (supplied in the WBEM subdirectory of the Windows system directory).

By contrast, consumption of these events in Windows Vista is bang up-to-date. Presentation in the Event Viewer depends on definitions in an instrumentation manifest, which Microsoft supplies as an <instrumentation> block within the manifest that represents SERVICES 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.

That these events are provided through MOF files but consumed through manifests turns out to have practical consequence, albeit very slight: as shown below, an error in the MOF file means that two events become one. Presumably, this has not confused anyone, else Microsoft might have corrected it by now.

Another consequence, but one which is noted only for completeness, is that the symbolic name for the provider GUID, as given in the manifest, is not actually used in the SERVICES code.

Possible Events

The large table that follows lists all the events that SERVICES registers with WMI for firing to the System log (not that this necessarily means that all these events actually can occur). Descriptions are reproduced from the relevant manifest and message-table resource in the SERVICES executable. Since the instrumentation manifest names the parameters only as param1, param2, etc, placeholders in the descriptions are instead resolved below from definitions in the SERVICES code and in SCM.MOF.

Event 7019 is unusual in that it originates in SERVICES.EXE as two distinct events. (The WMI class names are MSFT_NetDependOnLaterService and MSFT_NetDependOnLaterGroup.) That SCM.MOF translates them both to 7019 looks to be an editing error. The latter would better translate to 7020, which is indeed what the manifest gives as the value for the event that it represents as EVENT_DEPEND_ON_LATER_GROUP. The obvious experiment of setting a service’s DependOnGroup to name a later-loading group does indeed produce event 7019 instead of 7020, confirming that these events are delivered into the event log classically, i.e., using MOF files rather than a manifest.

In the description given above for event 7036, the second placeholder is reproduced correctly as Control, though clearly it does not stand for a control but a status. See the SCM.MOF entry for MSFT_NetServiceStatusSuccess. The grammatical error in the description of event 7003 is also reproduced from Microsoft.

A few events have parameters that are not used for the descriptions. Events 7031 and 7032 have an ActionType, as the fourth and first parameter respectively. Events 7035, 7040 and 7042 each have a sid as the last parameter. Event 7041 has an Error as the last parameter, but it can only be 0x0569 (ERROR_LOGON_TYPE_NOT_GRANTED), else the event would have been 7038.

For several events, comments in SCM.MOF suggest descriptive text that is slightly different (and sometimes very different) from what is shown above. They are just comments. What counts for display in the Event Viewer is what’s found in the manifest. That said, the manifest and the message-table resource in SERVICES.EXE both provide the following messages for IDs which SERVICES.EXE cannot ever fire as events and which SCM.MOF does not translate. Except for 7020, as discussed above, they are perhaps obsolete.