Downloads
125876_WMIActivity.zip

Windows Management Instrumentation (WMI) is a widely used technology on both Windows server and client, employed for tasks such as inventory of hardware and software, determining whether services or processes are running, and many others. Usually, WMI just works, but when it doesn't and you need to investigate it, doing so can be very difficult. For instance, one of the most common problems with WMI is high CPU spikes for the one of the provider processes (wmiprvse.exe). The provider process is where the WMI queries are executed, and the WMI service process (svchost.exe) is where the query results are returned to the process that executed the WMI query. As an administrator, you've probably either run into a high-CPU–usage issue with WMI or needed to view incoming WMI queries. In the course of investigating a high-CPU issue, it would be very beneficial to see the queries being executed and determine where the query came from.

Unfortunately, viewing incoming WMI queries is at best a cumbersome process that can frustrate administrators trying to answer the simple question "What WMI queries are being executed on my system?" In this article, I'll show you how to view the incoming queries as close to real time as possible, then correlate where the query is coming from. This will enable you to immediately troubleshoot common WMI high-CPU issues without having to perform complicated debugging steps or scan through hundreds of log file events—or make that dreaded support call.

Retrieving WMI Trace Logs
As described in the blog post "WMI Debug Logging," you can turn on the tracing mechanism inside the Event Viewer to view the tracing logs for WMI. However, because of the large number of events collected, it's difficult to determine the latest incoming queries, when they executed, and where they are coming from. Even the filtering mechanism built into the Event Viewer menu does not provide the ability to filter only on "WMI Queries".

Enter wevtutil.exe, the Windows Events Comand-Line Utility. Wevtutil, included in Windows Vista and later, lets you retrieve information about event logs as well as export, run queries, and set properties on the log files. For instance, Wevtutil can set the tracing flag on the WMI-Activity event log either locally or remotely, so that you can start receiving WMI trace logs in the Event Viewer interface.

Here is the exact syntax to set the tracing flag on the WMI-Activity log file (start an elevated command-prompt), along with a message displayed after you enter the command:

C:\Windows\system32>wevtutil sl Microsoft-Windows-WMI-Activity/Trace /e:true

 

**** Warning: Enabling this type of log clears it.  Do you want to enable and<br>clear this log? \\[y/n\\]:<br>y


Notice that you are asked to clear the log, which is required to enable the tracing option (note: It is not required to clear the log to disable the tracing flag). There is also /r option that lets you set the tracing flag on a remote system.

After the tracing flag is set, you will start to receive "Informational" events in the WMI-Activity event log, however the verbosity is high, and even if you wanted to use the filtering mechanism, you still would not be able to filter for just WMI queries. Again we will use wevtutil.exe to help us manually view the incoming WMI queries. Here is the syntax to view the WMI queries using Wevtutil (after enabling the tracing flag and from an elevated command prompt).

c:\>wevtutil qe Microsoft-Windows-WMI-Activity/Trace /q:"*\\[System\\[(Level=4 or Level=0) and (EventID=1)\\]\\]" |findstr /i execquery


The first option qe means "query events from a log file"; then the name of the log file is entered (Microsoft-Windows-WMI-Activity/Trace). The /q: option says to filter the event log for just those specific events; in this case we are asking for Level 4 or Level 0 AND Event ID=1, which is the event ID that all WMI queries are logged as. Then we pipe the results to findstr (find string) and filter for just the /execquery commands.