How to Clear the Windows WMI Repository Cache via PowerShell

The Management Infrastructure

Windows Management Instrumentation (WMI) is the core administrative framework of the Windows operating system. It provides a standardized interface for monitoring system health, querying hardware specifications, and executing administrative scripts. Almost every enterprise management tool—including Microsoft Endpoint Configuration Manager (SCCM), third-party antivirus agents, and native PowerShell cmdlets like Get-WmiObject—relies entirely on WMI to function.

The WMI engine stores its object schemas and definitions in a centralized, compiled database known as the WMI Repository. Over years of installing, updating, and removing complex software packages, this database can suffer severe corruption.

When the WMI Repository is corrupted, the symptoms are catastrophic for system administration: SCCM client deployments fail silently, Server Manager crashes upon opening, Group Policy stops applying, and running basic PowerShell queries throws vague COM exceptions (like 0x80041002 or “Invalid class”).

To restore administrative control, you must forcefully salvage and rebuild the WMI Repository cache using PowerShell.

Locating the Repository

The WMI Repository is a collection of deeply protected binary files located at:

C:\Windows\System32\wbem\Repository

Because the Windows Management Instrumentation service (Winmgmt) locks these files immediately upon boot, you cannot simply delete the folder. You must carefully shut down the dependent services and execute the native WMI repair utility.

Verifying Repository Corruption

Before you obliterate the database, you should verify that it is actually corrupted. Open an elevated Command Prompt or PowerShell as Administrator and run the native verification check:

winmgmt /verifyrepository

If the output says WMI repository is INCONSISTENT, you have definitive proof of corruption and must proceed with the rebuild.

Resetting the Cache via PowerShell

The rebuild process involves stopping the core service, dropping the active database, and forcing Windows to recompile the .mof (Managed Object Format) files back into a fresh repository.

Execute the following script carefully:

# 1. Stop the Windows Management Instrumentation service and all dependent services (like IP Helper and SCCM agent)
Stop-Service -Name Winmgmt -Force

# 2. Rename the corrupted repository folder (Safer than deleting)
Rename-Item -Path "C:\Windows\System32\wbem\repository" -NewName "repository.CORRUPT" -Force

# 3. Restart the WMI service. This forces Windows to instantly generate a blank repository folder.
Start-Service -Name Winmgmt

# 4. Force a complete rebuild of the repository to factory defaults
winmgmt /resetrepository

The Recompilation Phase

When you execute winmgmt /resetrepository, the terminal will hang for several seconds and eventually output: WMI repository has been reset.

At this point, the baseline Windows WMI classes are restored. However, third-party software (like your antivirus or hypervisor agents) that injected custom WMI classes into the old repository will now be broken because their definitions were wiped out.

To fix this, you must instruct Windows to recursively scan the system and automatically recompile every single registered .mof file back into the fresh database.

Execute this command to force a system-wide recompilation:

cd C:\Windows\System32\wbem\
for /f %s in ('dir /b *.mof *.mfl') do mofcomp %s

(Note: If you are running this in PowerShell rather than CMD, you must adjust the for loop syntax, or simply run cmd.exe first, paste the loop, and then type exit).

Verification

Once the recompilation finishes, run the verification command one last time:

winmgmt /verifyrepository

It should now report WMI repository is consistent. Your server’s administrative framework is fully restored, and SCCM policies will immediately begin processing again.