WMI Repository Corruption Detected: 3 Quick Fixes

1. Bad Shutdown or Update Glitch — Quick Rebuild

Nine times out of ten, this error shows up after a power outage, a forced restart during Windows updates, or a failed feature update. The corruption is superficial — the WMI repository has a few bad objects but isn’t totally hosed.

The culprit here is almost always a partial write to the CIM repository. Windows tries to save WMI data during shutdown, and if the power dies mid-write, you get a corrupted index.

The fix: Run the built-in salvage command. Open an elevated Command Prompt (Win+X, then Command Prompt (Admin) or Terminal (Admin)). Type this:

winmgmt /salvagerepository

This command scans the repository, finds corrupted objects, and rebuilds only those bits. It’s safe — won’t nuke your settings or break anything that works. Takes about 30 seconds.

If it completes without errors, reboot. Then check if the WMI error is gone by running wbemtest (just type wbemtest in Run or CMD) and connecting to root\cimv2. If it connects, you’re golden. If you get the same error (0x80041002), move to fix #2.

Don’t bother with winmgmt /verifyrepository first — it just tells you what you already know. Skip straight to salvage.

2. Deeper Corruption — Full Repository Reset

When salvage fails, the repository is too damaged to patch. This happens more often on Windows 10 21H2 or older builds that had poorly written third-party WMI providers. I’ve seen SQL Server and VMware tools corrupt the repo this way.

The fix: Reset the repository and re-register providers. Run these commands in order from an elevated CMD:

net stop winmgmt
winmgmt /resetrepository
winmgmt /registerserver
net start winmgmt

This deletes the entire repository and creates a fresh one. It then re-registers all WMI providers. Your system settings (like hardware config logs) will be rebuilt on next boot. The downside: any custom WMI namespaces from third-party apps (like HP Systems Insight Manager or Dell OpenManage) will need to be re-installed.

After the reset, run wbemtest again. If it connects, the problem is solved. If you still see errors, you might have a corrupt provider DLL — but that’s rare. More often, the reset works.

One gotcha: if you have a lot of custom WMI scripts or monitoring tools (like SolarWinds), back up the repository first. You can do that with winmgmt /backuprepository C:\wmi_backup.bak. But honestly, I’ve never needed it — the reset fixes the syntax, and the tools rebuild their data.

3. Provider or MOF File Gone Bad — Manual Removal

Still broken? Then it’s not the repository itself — it’s a corrupt Managed Object Format (MOF) file or a misbehaving provider that’s crashing WMI on load. This is the "chasing ghosts" scenario. You’ll know it because winmgmt /salvagerepository runs fine but WMI still throws errors in the event log (Event ID 10 or 36 from source WinMgmt).

The fix: Identify and disable the bad provider.

First, download Microsoft’s WMIDiag tool from the official MS download center. Run it with:

wmidiag /c /f

This generates a log file (WMIDiag.log in the temp folder). Scroll to the "Errors" section. It will list the provider name and the DLL path. Look for something like "Provider ‘HPWMI’ failed to load" or "Corrupt MOF: c:\windows\system32\wbem\some.mof".

Once you know the provider, disable it:

regsvr32 /u "path\to\bad.dll"

Or, if it’s a MOF file, you can try recompiling it with mofcomp:

mofcomp -MOF -MFL corrupted.mof

But honestly, the more reliable method is to find the provider in Registry Editor under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\Providers and delete the offending key. Back up the key first. Then restart the WMI service.

This is the hardest fix, but if you’re here, you’ve already tried the first two and they didn’t stick. In my experience, 90% of users are done after fix #1 or #2. This one’s for the last 10% who have someone’s poorly coded monitoring agent installed.

Quick Fix Summary Table

Start with the top row and work down. Don’t skip steps. And always reboot after each fix before testing. I’ve wasted hours testing WMI only to realize the service cache was stale.