Fix 0XC0000295: WMI GUID not recognized by provider

What this error actually means

You're getting 0XC0000295 (which maps to STATUS_WMI_NOT_FOUND). What's happening is your script, tool, or application passed a GUID (a class, method, or property identifier) to a WMI data provider — and that provider essentially said “I don't know what that is.”

This isn't a permissions issue or a network problem. It's almost always one of two things:

A corrupt WMI repository (common after failed updates, disk errors, or abrupt shutdowns)
A provider that's missing or didn't register its MOF files properly

I've seen this after installing a third-party monitoring tool that botched its WMI registration, or after a Windows Feature Update that left the repository in a half-baked state. The fix depends on how deep the damage is.

Fix 1: Quick WMI reset (30 seconds)

Before you do anything else, stop and restart the WMI service. This flushes temporary state and sometimes resolves transient GUID lookups.

Open an elevated Command Prompt (Run as Administrator).
Run these two commands back-to-back:

net stop winmgmt
net start winmgmt

If the service stops cleanly and starts again, test your original operation. If the error disappears, you had a stale cache — you're done.

If net start fails with “service did not respond,” move to Fix 2. That's a sign of a deeper repository problem.

Fix 2: Repository repair with winmgmt /salvagerepository (5 minutes)

WMI has a built-in salvage command that rebuilds the repository from the MOF definitions stored in %windir%\system32\wbem. It's non-destructive — it only fixes missing or corrupted objects, it doesn't blow away your custom namespaces.

Open an elevated Command Prompt.
Run:

winmgmt /salvagerepository

What's actually happening here is WMI parses every MOF file in the repository folder, re-registers the missing GUIDs, and cross-references them against the existing classes. This takes about 2–5 minutes on a modern system. You'll see no output until it's done.

When it finishes, restart the WMI service:

net stop winmgmt
net start winmgmt

Test your operation. If the error is gone, great. If not, or if the salvage command itself fails with an access violation, proceed to Fix 3.

Fix 3: Full repository rebuild — nuclear option (15+ minutes)

This is the real fix when the repository is so corrupt that even the salvage command can't parse it. You'll lose any custom WMI namespace registrations (like from third-party apps that added their own classes). You won't lose system functionality — Windows re-registers all built-in classes automatically.

Step 1: Stop the WMI service and delete the repository files.

net stop winmgmt
cd /d %windir%\system32\wbem
rd /s /q repository

Don't worry about the “access denied” on some files — the /q switch silences it, and WMI will recreate the folder structure on next restart.

Step 2: Re-register the default providers. This is the critical part. Run:

winmgmt /resetrepository

This command tells WMI to recreate the repository using the MOF files in the wbem folder. It's basically saying “start fresh from the golden image.”

Step 3: Manually compile all built-in MOF files. Skip this and you'll still get GUID errors for common classes like Win32_Process or Win32_Service.

for /f %f in ('dir /b *.mof') do mofcomp %f

This will take 5–10 minutes and produce a lot of output. You'll see some errors — that's normal, some MOF files depend on others and fail in isolation. The important thing is that the core system classes get registered.

Step 4: Restart WMI and reboot:

net start winmgmt
shutdown /r /t 0

After reboot, test your operation. If the error persists, you're dealing with a provider that didn't come from Microsoft — a third-party app (think backup agents, anti-virus, or management tools) that installed its own WMI provider and then got removed or corrupted. You'll need to reinstall that specific software.

When to stop and call it fixed

Test after each fix. Don't do all three out of habit. If the quick reset works, you saved yourself 15 minutes. If the salvage works, you avoided a full rebuild. The nuclear option is for when you can still see the error in Event Viewer's Applications and Services Logs > Microsoft > Windows > WMI-Activity > Operational with event ID 10 and the GUID still showing as unrecognized.

One more thing — if you're running Windows Server 2016 or older, the winmgmt /salvagerepository command is unreliable. Go straight to the full rebuild on those systems. I learned that the hard way.