How to Clear the Windows WMI Provider Host Cache via PowerShell

The WMI Subsystem

Windows Management Instrumentation (WMI) is the core administrative framework built into every modern Windows operating system. Whenever you use PowerShell to query the amount of free RAM (Get-WmiObject Win32_OperatingSystem), or whenever monitoring software like Datadog or PRTG polls the server for CPU usage, the request is processed by the WMI Provider Host service (WmiPrvSE.exe).

The WMI Provider Host acts as a middleman. It receives queries, reaches deep into the Windows kernel to gather the hardware telemetry, and then formats that data into a standardized database schema to return to the requester. To speed up these complex queries, WmiPrvSE.exe maintains a massive local cache of class definitions, namespaces, and recent query results.

However, if a third-party application constantly hammers the WMI service with malformed queries, or if the underlying WMI repository becomes corrupted during a sudden server reboot, the WMI Provider Host cache breaks. The symptom is unmistakable: you will open Task Manager and see WmiPrvSE.exe permanently consuming 100% of the CPU. The server will become incredibly sluggish, and PowerShell commands will simply hang indefinitely. To recover the server, you must forcefully purge the WMI Provider Host cache and reset the repository via PowerShell.

Locating the WMI Repository

The WMI cache and its primary database are heavily protected system files located deep within the Windows System32 directory, specifically at:

C:\Windows\System32\wbem\Repository

Because the WMI service is a critical component of the operating system, it locks these files aggressively. You cannot delete them via the GUI.

Purging the Cache via PowerShell

You must open an elevated PowerShell session as an Administrator. We must violently stop the WMI services, verify the repository state, and perform a hard reset.

Step 1: Analyzing the Repository State

Before deleting anything, you can ask Windows to perform a mathematical consistency check on the WMI database.

winmgmt /verifyrepository

If it returns WMI repository is INCONSISTENT, you have definitive proof of corruption.

Step 2: Terminating the WMI Services

You must stop the primary Windows Management Instrumentation service (Winmgmt). Because several other critical services depend on it (like the IP Helper), you must force it to stop.

Stop-Service -Name Winmgmt -Force -ErrorAction SilentlyContinue

Step 3: Obliterating the Local Cache

Now that the service is dead, you can safely navigate into the wbem directory and delete the entire repository folder. We will rename it to a backup file instead of a hard delete, just in case.

$WmiRepo = "C:\Windows\System32\wbem\Repository"
if (Test-Path $WmiRepo) {
    Rename-Item -Path $WmiRepo -NewName "Repository.OLD" -Force
    Write-Host "WMI Repository successfully disabled." -ForegroundColor Green
}

Step 4: Rebuilding the Repository

You must now restart the WMI service. When it starts, it will realize its database is missing.

Start-Service -Name Winmgmt

To force the WMI engine to completely rebuild the cache and recompile all of its internal classes (.mof files), execute the salvage command:

winmgmt /resetrepository

The system will output WMI repository has been reset.

The Recalibration

The moment you execute the reset command, the WMI engine will parse every single .mof file in the C:\Windows\System32\wbem\ directory, rebuilding a brand new, mathematically perfect database from scratch. The WmiPrvSE.exe process will instantly drop back down to 0% CPU utilization, and your third-party monitoring software will instantly resume functioning correctly without dragging the server to a halt.