WmiPrvSE.exe high CPU: find what is asking WMI so many questions

What WmiPrvSE.exe is

WmiPrvSE.exe is the WMI Provider Host. Windows Management Instrumentation answers questions about the machine (hardware, services, performance) for monitoring tools, scripts and management agents, and this process runs the providers that supply those answers. It is busy because something is asking, so the work is finding who.

1. Confirm the process, and how many there are

Get-CimInstance Win32_PerfFormattedData_PerfProc_Process -Filter "Name='WmiPrvSE'" |
  Select-Object Name, IDProcess, PercentProcessorTime
Get-CimInstance Win32_Process -Filter "Name='WmiPrvSE.exe'" |
  Select-Object ProcessId, CreationDate, CommandLine

Several instances can run at once, one per provider host. Note the process ID of the busy one and how long it has been running (CreationDate).

2. Find what is asking

WMI keeps an activity log. Failed operations record the client process that made the request, and providers being loaded are recorded too.

Get-WinEvent -LogName 'Microsoft-Windows-WMI-Activity/Operational' -MaxEvents 50 |
  Select-Object TimeCreated, Id, @{n='Message';e={$_.Message.Substring(0,[Math]::Min(220,$_.Message.Length))}}

Event 5858 records a failed operation and includes the client process ID, which you can look up with Get-Process -Id. Events 5860 and 5861 record WMI event subscriptions, and a permanent subscription is something a legitimate product or an attacker can leave behind, so note the consumer name and where it came from rather than deleting it.

Monitoring and backup software that polls WMI very often is commonly reported as the cause. Look for a product that started recently or was reconfigured.

3. Check the repository is healthy

winmgmt /verifyrepository

A healthy repository reports that it is consistent. An inconsistent one is a cause in its own right and makes callers retry, which keeps providers busy.

4. Fixes, least invasive first

1. Stop or slow the client you identified. A polling interval of seconds is rarely needed; a monitoring tool can usually be set to minutes.
2. Restart the WMI service to clear a stuck provider host. This also stops services that depend on it, so do it when the user can tolerate a brief interruption.
3. Repair an inconsistent repository with winmgmt /salvagerepository first. winmgmt /resetrepository is the last resort.

Restart-Service winmgmt -Force

/resetrepository returns the repository to its initial state, which can remove registrations that third-party software added to WMI. Anything that depends on those registrations may need to be reinstalled or repaired afterwards, so use it only when salvage did not work, and after telling the customer.

5. Verify

Measure again over several minutes and re-run winmgmt /verifyrepository. If the busy process comes back when the same tool runs, that tool, not WMI, is the thing to fix.

Where RemediateDesk fits

RemediateDesk runs the measurement, the activity-log read and the repository check as read-only steps and reports what it found, including which process was asking. Restarting the WMI service or repairing the repository is proposed as one exact command and waits for approval, and the ticket is not closed on the strength of the command exiting cleanly; a separate check has to confirm the repository verifies.

Frequently asked questions