Geoff Chappell, Software Analyst
Several tens of KB of the SERVICES.EXE file in Windows Vista is explained by WPP Software Tracing. Microsoft is surely correct that “the performance cost of software tracing is very small” and even that “the code is minimized” (see What is the performance cost of tracing when no one is listening? in the Windows DDK), but note that minimized does not necessarily mean small, especially not when accumulated over numerous events.
Provider Name: | Service Control Manager Trace |
Provider GUID: | {EBCCA1C2-AB46-4A1D-8C2A-906C2FF25F39} |
Symbolic Name for GUID: | WPP_ThisDir_CTLGUID_Regular |
This trace provider is ordinarily not configured in the registry. It is therefore not listed as a publisher by WEVTUTIL and no session listed by either WEVTUTIL or the Event Viewer receives events from this provider. However, it is always logging! Whenever SERVICES starts, it starts a trace session, named SCM, and it enables this provider in that session. It can therefore be controlled through the Reliability and Performance Monitor, where it is listed among the Event Trace Sessions. The log file for the SCM session can be loaded into the Event Viewer for inspection.
The name and location of the log file for the SCM session is hard-coded:
Directory: | %windir%\system32\LogFiles\Scm |
Filename: | SCM.EVM |
The maximum file size, which is ordinarily 50MB, can be set from an environment variable, named SCMLogSize. This variable’s value is a decimal number of MB. Everything else about the log file is hard-coded.
The log file is operated in circular mode, but SERVICES itself manages log files for previous sessions. Each time that SERVICES starts, it renames the existing SCM.EVM file to a backup. There can be as many as five such backups, with names from SCM.EVM.1 to SCM.EVM.5 inclusive. Thus, whether you knew it or not, whether you wanted it or not, your switched-off computer typically has a very detailed record of what SERVICES executed in each of the previous five times that you started Windows.
The provider’s enable flags are configurable through the registry:
Key: | HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Tracing\SCM\Regular |
Value: | Flags |
Though the data type REG_DWORD is surely expected, this is not enforced and up to four bytes of any data type are accepted. The default is 0x0FF3F7FF. The following table shows the interpretation of bits as defined in SERVICES.MOF. They are accessible in the Reliability and Performance Monitor as the “Keywords(Any)” property for the provider.
Bit | Interpretation | Remarks |
---|---|---|
0x00000001 | ERROR Flag | |
0x00000002 | WARNING Flag | |
0x00000004 | TRACE Flag | |
0x00000008 | INFO Flag | |
0x00000010 | SECURITY Flag | |
0x00000020 | CONFIG Flag | |
0x00000040 | DEPEND Flag | |
0x00000080 | DEPEND_DUMP Flag | |
0x00000100 | CONFIG_API Flag | |
0x00000200 | LOCK_API Flag | |
0x00000400 | ACCOUNT Flag | |
0x00000800 | USECOUNT Flag | not enabled by default |
0x00001000 | NETBIOS Flag | not used in code |
0x00002000 | THREADS Flag | |
0x00004000 | BSM Flag | |
0x00008000 | SHUTDOWN Flag | |
0x00010000 | WHY Flag | |
0x00020000 | BOOT Flag | |
0x00040000 | HANDLE Flag | not enabled by default |
0x00080000 | LOCKS Flag | not enabled by default |
0x00100000 | CONTROL Flag |
Note that although the Reliability and Performance Monitor can change properties of the session or provider, including even to get events written to a different log file, such changes are at best temporary. When SERVICES next starts, typically when Windows next starts, it reverts to hard-coded properties except for the maximum file size and the enable flags.
Windows does not supply any definitions for formatting events from this trace provider. A GUID corresponds to a source file and the event ID selects a trace statement in that source file. Parameters, such as shown in the EventData on the Details tab in the Event Viewer, vary from one trace statement to another. SERVICES presently provides for well over a thousand trace statements.