Edit

Share via

Troubleshoot WMI high CPU usage issues

  • Article

This article covers how to diagnose Windows Management Instrumentation (WMI) high CPU usage issues on any Windows operating system.

Identify the problem

In most scenarios, the CPU is consumed by the WmiPrvse.exe process, and there are a few instances where svchost.exe hosting the WMI service (Winmgmt) is consuming high CPU usage.

Review the Task Manager's Processes pane or Details pane to identify the exact process

Identify if the process is WmiPrvse.exe or svchost.exe (hosting the WMI service Winmgmt), and identify the process ID.

Note

You may have to manually add the PID column to view the process ID of all the processes in Task Manager.

Here's an example. Go to Task Manager > Details, then sort by Name and locate the WmiPrvse.exe process that's consuming high CPU usage. Make a note of the process ID (PID).

This screenshot shows multiple instances of WMI Provider Host (the WmiPrvse.exe process) as active and its CPU utilization.

Screenshot shows the process via task manager.

This screenshot shows Services Host: Windows Management Instrumentation (svchost.exe hosting the Winmgmt service) and its CPU utilization.

Screenshot shows the details via task manager.

Go to Task Manager > Services, sort by Name, and locate the Winmgmt service. Make a note of the PID. Right-click the service and select Go to details to locate the svchost.exe process as follows:

Screenshot shows the services via task manager.

In the example, out of three WmiPrvse.exe instances, PID 3648 is located, which consumes around 25% of CPU usage. Winmgmt is hosted under the svchost.exe process with PID 2752.

Understand the CPU consumption

This involves mainly observing the overall CPU consumption and the PID identified. It's important to note when, how, and the frequency of the CPU consumption.

Assess the situation by understanding if the CPU consumption is high during a specific time. Check if there's any activity, such as running specific tasks or services active, running monitoring applications, or running scripts leading to WmiPrvse.exe or Winmgmt high CPU.

Understand if there's any pattern, which means CPU usage is consistent, inconsistent, random, sporadic, or has regular spikes.

Identify the frequency of the CPU consumption. Check if it occurs only during production hours, out-of-business hours, or a random time of the day. It may also occur during a specific activity like user sign in or sign out.

You may use Task Manager and visually make a note of how the CPU usage pattern is.

Here's an example that shows how to use the Performance Monitor (Perfmon) tool to identify the exact instances of WmiPrvse.exe with the PID you identified. You can also get a graphical view of the CPU consumption of any process (WmiPrvse.exe or svchost.exe hosting WMI service).

  1. Open an elevated command prompt, and enter Perfmon.

  2. Select Performance Monitor in the left pane, and select the plus sign (+) in the right pane to open the Add Counters window.

  3. Expand Process and select ID Process. Select all the WmiPrvse# instances, and then select Add > OK.

    Screenshot shows how to add ID Process counters.

    Screenshot shows the details of the ID Process counters.

  4. In the Add Counters window, expand Process and select %Processor Time. Select the WmiPrvse# matching the PID consuming high CPU usage, and then select Add > OK.

    Screenshot shows how to add %Processor Time counters.

    Screenshot shows the details of the %Processor Time counters.

  5. For the "ID Process" counter, the Last, Average, Minimum, and Maximum all represent the PID of the respective WmiPrvse.exe process. Once you have identified the exact instance that's consuming high CPU usage, you may remove the remaining instances of WmiPrvse# instances from the list by pressing Delete.

In the example, it's noted that WmiPrvse.exe PID 556 was consuming high CPU usage, and it's WmiPrvse#1 that matches PID 556 in Performance Monitor.

Then counter %Processor Time of WmiPrvse#1 is added to see a live graphical view of the CPU usage of this process. In the example, the %Processor Time color of WmiPrvse#1 is changed from yellow to red.

The steps are the same for locating the right svchost# in Performance Monitor in the case of high CPU usage by svchost.exe hosting the Wmimgmt service.

If you observe that a svchost.exe process hosting the WMI service is causing high CPU usage and suspect that WMI is contributing to the issue, you can confirm if the PID of the svchost.exe process is hosting the WMI service by running the following command:

tasklist /svc /fi "Services eq Winmgmt"

If the svchost.exe process contains multiple services, you can break apart the WMI service into its own svchost.exe process by following these steps:

  1. Open an elevated command prompt with elevated privileges.

  2. Run the following command:

    sc config Winmgmt type= own

  3. Restart the WMI service.

After restarting the service, you may run the Tasklist /svc command to check if the Winmgmt service is running under its own svchost.exe process.

After resolving the issue or no longer requiring the service to be in its own svchost.exe process, you can place it back into the shared svchost.exe process. You can perform the action by running the following command from a command prompt and then restarting the WMI service again:

sc config Winmgmt type= share

Diagnose WmiPrvse.exe

So far, you only have the exact PID of WmiPrvse.exe that's consuming high CPU usage. Next, gather as much information as possible about this PID. This helps you assess the situation or identify something that could be causing the problem. Gather information on other resource usage or identify the exact WMI provider (DLL) hosted by the WmiPrvse.exe PID identified.

Other resource usage such as memory, handles, threads, and username

Gather information on other resource usage, such as memory, handles, threads, and username, at the time of high CPU usage. You may use the Details tab in Task Manager, select the exact PID, and review it.

Note

Add additional columns as needed.

Screenshot shows the high CPU usage service in Task Manager.

Identify the exact WMI provider (DLL) hosted by the WmiPrvse.exe PID identified

There are multiple methods to identify the provider(s) loaded in the WmiPrvSE.exe process.

  1. Use Scripts: List all running WMI providers to output all running Windows Management Instrumentation (WMI) providers.

  2. Process Explorer can help you identify the exact providers hosted in the PID identified. Follow these steps:

    1. Run Process Explorer as an administrator. Locate the identified WmiPrvse.exe PID, go to its properties, and select the WMI Providers tab.

    2. In the following example, WmiPrvse.exe PID 556 is located and found to be hosting:

      • WMI provider: MS_NT_EVENTLOG_PROVIDER
      • Namespace: root\CIMV2
      • DLL path: %systemroot%\system32\wbem\ntevt.dll

      Screenshot shows the WmiPrvSE.exe:556 properties.

  3. In most cases, there may be more than one provider loaded. It may be any of the providers that are spending time in the CPU, causing high CPU issues.

Sometimes, if the issue is intermittent or infrequent, the WmiPrvse.exe causing the issue may be terminated over time. When the issue occurs again, it may be the same provider(s) in a new WmiPrvse.exe instance. In this situation, once you have the provider(s) noted, run the following cmdlet to show the current PID of the WmiPrvse.exe process containing that provider:

tasklist /m <Provider DLL>

Here's an example:

tasklist /m ntevt.dll

Screenshot shows the tasklist output of the ntevt.dll file.

Hence, it's important to understand what providers are loaded in the WmiPrvse.exe process and make a note of the PID of the WmiPrvse.exe process every time.

Once you have the provider(s) that are loaded in the WmiPrvse.exe causing high CPU usage, you can understand if it's handling any tasks.

Tasks may be the incoming WMI queries that are submitted by the client process to the WMI service, which then is assigned to the appropriate WMI provider process. In the example, the task is submitted to the MS_NT_EVENTLOG_PROVIDER provider. So the next step will be to study the incoming queries and tasks to the MS_NT_EVENTLOG_PROVIDER provider.

Analyze the incoming queries

Examining incoming queries involves:

  • Identifying WMI query(s) that are handled by WMI providers causing high CPU usage.
  • WMI class(es) queries.
  • An associated user.
  • A client process that's initiating the query.

The above information can be gathered using the publicly available tool WMIMon or WMI-Activity Operational logs and WMI-Tracing available under Event Viewer.

Operational logs: Microsoft-Windows-WMI-Activity/Operational

The incoming queries are logged as operational events in the Microsoft-Windows-WMI-Activity/Operational log, which is available under:

Event Viewer > Applications and Services Logs > Microsoft > Windows > WMI-Activity

There are several types of events logged.

If the WmiPrvse.exe process consuming high CPU is terminated from time to time, and you already know what provider(s) are loaded, the following event may help determine the currently active WmiPrvse.exe process hosting the provider in question.

Log Name:      Microsoft-Windows-WMI-Activity/Operational
Source:        Microsoft-Windows-WMI-Activity
Event ID:      5857
Task Category: None
User:          NETWORK SERVICE
Description:
MS_NT_EVENTLOG_PROVIDER provider started with result code 0x0. HostProcess = wmiprvse.exe; ProcessID = 556; ProviderPath = %systemroot%\system32\wbem\ntevt.dll

Enable "Analytic and Debug Logs" for enabling the WMI tracing

In Event Viewer, select View > Show Analytic and Debug Logs to enable the Debug and Trace for WMI-Activity.

Screenshot shows Operational in Event Viewer.

Debug and Trace are disabled by default, and each of them can be enabled manually by right-clicking Trace or Debug and then selecting Enable Log.

Note

Enabling Show Analytic and Debug Logs enables debug and tracing for almost all the event sources and creates additional logging. Hence this has to be disabled once the investigation is complete and will not be in use anymore.

This tracing can be kept enabled while you observe high CPU consumption by the WmiPrvse.exe process or long enough to capture the behavior of high CPU usage to keep the logs clean and moderately sized for easier analyzing of traces.

  1. Export the traces by right-clicking Trace and selecting Save All Events As….

  2. Select .xml or .csv in Save as type.

    Note

    You may choose other familiar formats such as .EVTX as needed.

  3. Choose the desired language of the tracing file.

  4. You may choose to save the WMI-Activity Operational events separately as well, in the desired format for you to review and analyze.

Review the WMI trace files

Within the WMI tracing, there are multiple important operations included, which are all part of incoming WMI queries. The operations are documented in IWbemServices interface (wbemcli.h).

Some of the important operations are:

  • IWbemServices::ExecQuery method (wbemcli.h)
  • IWbemServices::ExecMethod method (wbemcli.h)
  • IWbemServices::ExecQueryAsync method (wbemcli.h)

Here's one of the log entries from the WMI-Tracing CSV file saved:

Level Date and time Source Event ID Task category Description
Information 05-05-23 14:48 Microsoft-Windows-WMI-Activity 11 None CorrelationId = {345E5566-0000-0000-0000-68343241D901}; GroupOperationId = 30693; OperationId = 30694; Operation = Start IWbemServices::ExecQuery - root\cimv2 : select * from Win32_Product; ClientMachine = 21H2W10M; User = CONTOSO\<UserName>; ClientProcessId = 5484; NamespaceName = 133277000000783520

A similar event in XML format looks like:

 <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
<System> 
<Provider Name="Microsoft-Windows-WMI-Activity" Guid="{1418ef04-b0b4-4623-bf7e-d74ab47bbdaa}"/> 
<EventID>11</EventID> 
<Version>0</Version> 
<Level>4</Level> 
<Task>0</Task> 
<Opcode>0</Opcode> 
<Keywords>0x8000000000000000</Keywords> 
<TimeCreated SystemTime="2023-05-05T13:09:18.7442455Z"/> 
<EventRecordID>112</EventRecordID> 
<Correlation ActivityID="{eddc1bfb-0000-0000-0000-18b6cabf5949}"/> 
<Execution ProcessID="2752" ThreadID="4132"/> 
<Channel>Microsoft-Windows-WMI-Activity/Trace</Channel> 
<Computer>21H2W10M.contoso.com</Computer> 
<Security UserID="S-1-5-18"/> 
</System> 
<UserData> 
<Operation_New xmlns="http://manifests.microsoft.com/win/2006/windows/WMI"> 
<CorrelationId>{345E5566-0000-0000-0000-67343241D901}</CorrelationId> 
<GroupOperationId>28089</GroupOperationId> 
<OperationId>28090</OperationId> 
<Operation>Start IWbemServices::ExecQuery - root\cimv2 : select * from Win32_Product</Operation> 
<ClientMachine>21H2W10M</ClientMachine> 
<ClientMachineFQDN>21H2W10M.contoso.com</ClientMachineFQDN> 
<User>CONTOSO\<UserName></User> 
<ClientProcessId>5484</ClientProcessId> 
<ClientProcessCreationTime>133277000000783520</ClientProcessCreationTime> 
<NamespaceName>\\.\root\cimv2</NamespaceName> 
<IsLocal>true</IsLocal> 
</Operation_New> 
</UserData> 
<RenderingInfo Culture="en-US"> 
<Message>CorrelationId = {345E5566-0000-0000-0000-67343241D901}; GroupOperationId = 28089; OperationId = 28090; Operation = Start IWbemServices::ExecQuery - root\cimv2 : select * from Win32_Product; ClientMachine = 21H2W10M; User = CONTOSO\<UserName>; ClientProcessId = 5484; NamespaceName = 133277000000783520</Message> 
<Level>Information</Level> 
<Task/> 
<Opcode>Info</Opcode> 
<Channel/> 
<Provider>Microsoft-Windows-WMI-Activity</Provider> 
<Keywords/> 
</RenderingInfo> 
</Event>

From the above sample operation output, you can get and understand the following information:

  • A query was initiated on: 2023-05-05 at 13:09:18
  • On machine: 21H2W10M,
  • From a client PID: 5484
  • Operation ID: 28089
  • Query: select * from Win32_Product
  • Namespace: \\.\root\cimv2
  • Operation: IWbemServices::ExecQuery

Here's another log:

Level Date and time Source Event ID Task category Description
Information 05-05-23 14:47 Microsoft-Windows-WMI-Activity 12 None ProviderInfo for GroupOperationId = 30641; Operation = Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent; HostID = 556; ProviderName = MS_NT_EVENTLOG_PROVIDER; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E}; Path = %systemroot%\system32\wbem\ntevt.dll

The same event in XML format:

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> 
<System> 
<Provider Name="Microsoft-Windows-WMI-Activity" Guid="{1418ef04-b0b4-4623-bf7e-d74ab47bbdaa}"/> 
<EventID>12</EventID> 
<Version>0</Version> 
<Level>4</Level> 
<Task>0</Task> 
<Opcode>0</Opcode> 
<Keywords>0x8000000000000000</Keywords> 
<TimeCreated SystemTime="2023-05-05T13:09:18.8438242Z"/> 
<EventRecordID>120</EventRecordID> 
<Correlation ActivityID="{2a353ead-0000-0000-0000-256f9de5fabd}"/> 
<Execution ProcessID="2752" ThreadID="4348"/> 
<Channel>Microsoft-Windows-WMI-Activity/Trace</Channel> 
<Computer>21H2W10M.contoso.com</Computer> 
<Security UserID="S-1-5-21-0000000000-0000000000-00000000-1103"/> 
</System> 
<UserData> 
<Operation_Provider_Info_New xmlns="http://manifests.microsoft.com/win/2006/windows/WMI"> 
<GroupOperationId>28096</GroupOperationId> 
<Operation>Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent</Operation> 
<HostId>556</HostId> 
<ProviderName>MS_NT_EVENTLOG_PROVIDER</ProviderName> 
<ProviderGuid>{FD4F53E0-65DC-11d1-AB64-00C04FD9159E}</ProviderGuid> 
<Path>%systemroot%\system32\wbem\ntevt.dll</Path> 
</Operation_Provider_Info_New> 
</UserData> 
<RenderingInfo Culture="en-US"> 
<Message>ProviderInfo for GroupOperationId = 28096; Operation = Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent; HostID = 556; ProviderName = MS_NT_EVENTLOG_PROVIDER; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E}; Path = %systemroot%\system32\wbem\ntevt.dll</Message> 
<Level>Information</Level> 
<Task/> 
<Opcode>Info</Opcode> 
<Channel/> 
<Provider>Microsoft-Windows-WMI-Activity</Provider> 
<Keywords/> 
</RenderingInfo> 
</Event>

From the operation output of the second example, you can get and understand the following information:

  • Operation CreateInstanceEnum is initiated on behalf of the user with SID: UserID="S-1-5-21-0000000000-0000000000-00000000-1103"
  • On 2023-05-05 at 13:09
  • Exact operation: Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent
  • Host ID: 556
  • Provider name: MS_NT_EVENTLOG_PROVIDER
  • Provider path: %systemroot%\system32\wbem\ntevt.dll

Find the client PIDs that causing high CPU usage

The idea of reviewing this log file is to list the operations associated with the identified WmiPrvse.exe PID that's consuming high CPU usage, understand the incoming queries, and who's initiating them (the client process).

In the example covered above, it's the PID 552 that is causing high CPU usage.

From the second example of the log output, the operation CreateInstanceEnum is initiated for specific WMI class Win32_NTLogEvent.

For more information, see Win32_NTLogEvent, which includes the WMI provider details that are associated with the WMI class.

You now know the exact WMI provider hosted (MS_NT_EVENTLOG_PROVIDER) in the WmiPrvse.exe that's causing high CPU usage, the host ID (552), and WMI class (Win32_NTLogEvent) that's being queried by some client process.

Depending on the tool that you're using to review the trace files, you may apply necessary filters to review just the operations related to Win32_NTLogEvent or WmiPrvse.exe PID 552 or Host ID 552 or ntevt.dll.

With the filter showing only the lines or operations that include "Win32_NTLogEvent", the results are:

Level Source Event ID Description
Information Microsoft-Windows-WMI-Activity 11 CorrelationId = {345E5566-0000-0000-0000-68343241D901}; GroupOperationId = 30641; OperationId = 30642; Operation = Start IWbemServices::CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent; ClientMachine = 21H2W10M; User = CONTOSO\<UserName>; ClientProcessId = 5484; NamespaceName = 133277000000783520
Information Microsoft-Windows-WMI-Activity 12 ProviderInfo for GroupOperationId = 30641; Operation = Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent; HostID = 556; ProviderName = MS_NT_EVENTLOG_PROVIDER; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E}; Path = %systemroot%\system32\wbem\ntevt.dll
Information Microsoft-Windows-WMI-Activity 11 CorrelationId = {345E5566-0000-0000-0000-68343241D901}; GroupOperationId = 30697; OperationId = 30698; Operation = Start IWbemServices::CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent; ClientMachine = 21H2W10M; User = CONTOSO\<UserName>; ClientProcessId = 5484; NamespaceName = 133277000000783520
Information Microsoft-Windows-WMI-Activity 12 ProviderInfo for GroupOperationId = 30697; Operation = Provider::CreateInstanceEnum - MS_NT_EVENTLOG_PROVIDER : Win32_NTLogEvent; HostID = 556; ProviderName = MS_NT_EVENTLOG_PROVIDER; ProviderGuid = {FD4F53E0-65DC-11d1-AB64-00C04FD9159E}; Path = %systemroot%\system32\wbem\ntevt.dll

From the above operations, you can get the following additional information:

  • Timestamp
  • Operation ID: 30642;
  • The exact operation = Start IWbemServices::CreateInstanceEnum - root\cimv2 : Win32_NTLogEvent;
  • Client Machine = 21H2W10M
  • User = CONTOSO\<UserName>
  • PID of Client that has initiated the query: 5484

At last, you have the PID of a client process 5484, that's initiating a query to Win32_NTLogEvent. That's handled by provider MS_NT_EVENTLOG_PROVIDER and hosted under WmiPrvse.exe PID 552, which causes high CPU usage.

Once you have narrowed down the client PIDs, use one of the following tools to find the process name.

More information on WmiMon

WMImon.exe is a powerful monitoring tool that allows for the tracking and monitoring of system events and the resource usage of the WMI service.

It serves the important function of identifying the WMI calls and queries made by other processes, as well as providing information on query frequency, the user account used for the queries, and the requested information.

This data can be useful for system administrators who need to troubleshoot performance issues.

To collect and analyze this data, you can follow the step-by-step instructions:

  1. Identify the PID of the WmiPrvSE.exe that's consuming the CPU usage using the methods described above.
  2. Download the WMIMon.exe tool from GitHub - luctalpe/WMIMon. The tool is to monitor WMI activity on Windows.
  3. Extract the contents of the WMIMon_Binaries.zip file to a folder on your computer.
  4. Open a command prompt as an administrator and go to the folder where you extracted the WMIMon files.
  5. Execute the WMIMon.exe file by entering WMIMon.exe in the command prompt and pressing Enter.
  6. WMIMon will now start monitoring the WMI calls made by processes on the system, including the one identified in step 1.
  7. WMIMon displays information such as the client process ID, the WMI namespace called by the operation, the WMI class name, and the user account used to make the request.
  8. Analyze the output from WMIMon to identify which process(es) is making frequent WMI calls and potentially causing high CPU usage.

By following these steps, you can effectively use WMIMon.exe to monitor WMI activity on your system and identify any performance or security issues caused by excessive WMI usage.

Here's an example:

Screenshot shows the data captured by WMIMon.

Note

You can export the data captured by WMIMon to a text file by executing the WMIMon.exe > Data.txt command in the command prompt. To stop the data capture, press Ctrl + C.

There may be tricky situations where narrowing down a specific client PID, application, or EXE is impossible. In such cases, considering a common entity such as a user name or machine associated may be useful.

That is, understand if the user initiating the query is a service account or associated with a specific application.

Other solutions

Once you finalize the suspect, you may consider temporarily disabling its service or uninstalling the application associated with it and checking if the high CPU usage issue gets solved.

Here are some scenarios where disabling it can validate your observations.

  • Monitoring applications and services
  • System center configuration manager (SCCM) (policyhost.exe or Monitoringhost.exe)
  • Powershell.exe running scripts containing WMI queries
  • Any third-party application

Data collection

If you need assistance from Microsoft support, we recommend you collect the information by following the steps mentioned in Gather information by using TSS for User Experience issues.

  1. Download TSS.zip and extract the contents.

  2. Start the tracing by running the following cmdlet from an elevated PowerShell command prompt. Keep the tracing running when the machine is experiencing a high CPU issue or reproducing the issue.

    .\TSS.ps1 -UEX_WMIBase -WIN_Kernel -ETWflags 1 -WPR CPU -Perfmon UEX_WMIPrvSE -PerfIntervalSec 1 -noBasicLog

    Note

    Keep the tracing running for more than two minutes. Make sure the issue is reproduced during this window.

  3. Stop the tracing by following instructions in the PowerShell command prompt as per the TSS toolset.

The script will create a zip file containing the results of all traces and the diagnostic information. After a support case is created, this file can be uploaded to the secure workspace for analysis.