Welcome back. After our series of posts on Windows Server 2008, today we’re going to switch gears a little bit and look at WMI Logging. We often get calls from customers regarding WMI issues beyond the Permissions or Impersonation Rights problems that we’ve discussed in previous posts. In many of these cases, the WMI provider may be hanging or is consuming an inordinate amount of resources. The problem is trying to identify what exactly is going on when the issue surfaces. One way to do this is by enabling some debug logging for WMI.
For Windows XP and Windows Server 2003, the log files created by WMI and various providers record events, trace or diagnostic data, errors and other activities. Only a user with administrative privileges could access the WMI Logs folder. On Windows 2000 and Windows NT 4.0, non-administrators could read the logs in the WMI log folder. Enabling logging on Windows XP / Windows Server 2003, is a fairly simple process that does not require any service restarts (unless you change the log file location). To enable logging, open the Computer Management MMC snap-in, expand the Services and Applications section and select WMI Control as shown in the image below:
Right-click on WMI Control and select Properties. This brings up the WMI Control Properties dialog. Select the Logging tab:
On this tab, you can set the various logging levels for WMI, the maximum size and location of the log file. You can also set the Logging Options through the modification of the appropriate values in this Registry Key: HKLM\Software\Microsoft\WBEM\CIMOM.
Changing the value for Logging determines the logging level for WMI. The possible values are:
- 0 – No Logging / Disabled
- 1 – Log Errors Only
- 2 – Verbose Logging
As indicated above, changes to the logging level take place immediately and there is no requirement to restart the WMI service. If you modify the location of the WMI Log files however, you will need to restart the WMI service. For the moment, I am setting the logging level to verbose and running a very simple query using the WBEMTEST utility. The query I am using is Select * from Win32_ComputerSystem – which returns the name of the machine:
If I look in the Log Folder directory, there are several log files to choose from. The WBEMCORE.LOG file is the one I need to review to see what was logged when I ran the query. Within this log, I can find the event for this particular query:
So, I can tell what query was running and at what time (the time in the logs reflects the local time on the system). This information can be used to identify what WMI tasks may have been running when an issue occurred. However, the logs are not especially user-friendly. Enter Windows Vista …
The WMI service does not use the WMI Log files in Windows Vista. Instead, we use Event Tracing for Windows (ETW) and events that are available through the Event Viewer UI or the WEVTUTIL command line tool. To enable WMI tracing through Event Viewer, the first thing we have to do is show the Analytic and Debug Logs. Click on View, then select Show Analytic and Debug Logs:
Once these logs are displayed, you will be able to enable tracing. Expand the Applications and Services Logs section and then the Microsoft \ Windows sections:
Find the WMI-Actiivity folder and expand it – you should see a Trace log below that:
Right click on the Trace log and select Enable Log. That’s it. Trace Logging is enabled. To change the log size, you have to disable the logging first, then set the size and re-enable logging. So now that I have logging enabled, let’s run the exact same query from WBEMTEST again. Within the Trace Log, I can see lots of events – and the format is much more user friendly:
I can track the operation ID, see the query that was executed, the client machine that it was executed on, the User name, the Client Process ID and the Namespace to which I was connected all from one event. This makes tracing the events within WMI much easier when trying to track down problems.
OK, that will do it for this post. Until next time …