WMI 0x00001068 Fix: Data Provider Not Recognized

You'll see 0x00001068 when something calls into WMI and the provider on the other end rejects the payload. The literal message is The passed was not ERROR_WMI_ _NOT_FOUND recognized as valid by a WMI data provider — Microsoft's string table is mangled, but the meaning is clear: the provider got handed data it doesn't know how to handle, or the provider itself isn't fully registered. You'll hit it from PowerShell Get-WmiObject calls, from SCCM client inventory, from backup agents, and from monitoring tools querying perf classes.

The culprit is almost always a damaged WMI repository or a MOF that never compiled cleanly. I've fixed this on Windows Server 2016, 2019, and Windows 10 boxes after bad patch cycles and after third-party agents uninstalled themselves halfway. Let's walk through the three real causes.

Cause 1: Corrupted WMI Repository

This is the one you'll see most often. The repository at %windir%\System32\wbem\Repository is an ESE database. It gets hammered by every monitoring agent, every inventory scan, and every logon script that touches WMI. When it goes sideways, providers can't resolve their class definitions and you get 0x00001068 on otherwise valid calls.

First, verify the repo is actually the problem:

winmgmt /verifyrepository

If it returns WMI repository is inconsistent, don't waste time — rebuild it. Salvage is quicker but only works maybe 40% of the time in my experience. Here's salvage first, since it preserves custom classes:

1. Open an elevated command prompt.
2. Run net stop winmgmt. If it hangs, use sc query winmgmt to check state, then taskkill /f /im WmiPrvSE.exe.
3. Rename %windir%\System32\wbem\Repository to Repository.old.
4. Run winmgmt /salvagerepository. It'll rebuild from the old folder.
5. Verify again with winmgmt /verifyrepository.
6. If salvage fails or still reports inconsistency, delete the new Repository folder and run winmgmt /resetrepository.
7. Reboot. Don't skip this.

Do not run /resetrepository on a machine that has custom WMI providers from vendors like SolarWinds, Dell OMSA, or HP SIM. Reset wipes their namespace registrations and you'll be recompiling MOFs by hand afterward. Salvage first, always.

After the rebuild, run mofcomp %windir%\System32\wbem\*.mof won't work as a glob — you have to do it one at a time, and I've got a script for that in the next section.

Cause 2: Broken or Uncompiled MOF Files

Every WMI provider ships with a MOF file that registers its classes. When an installer crashes mid-way, or a patch rollup replaces a MOF but the compile step fails silently, you get orphaned class definitions. Calling into them throws 0x00001068 because the provider can't map the incoming data to a registered class.

Typical trigger: an SCCM client upgrade rolls back, or you install an AV agent that registers a WMI provider, then uninstall it. The MOF is gone but the repository still references it.

Recompile all base MOFs from an elevated prompt:

cd /d %windir%\System32\wbem
for %i in (*.mof) do mofcomp "%i"

If you're in a batch file, double the percent signs: %%i. Watch the output — any file that returns Parser error or 0x8004401e is your problem child. Common offenders on Windows Server are cimwin32.mof, wmipcima.mof, and dsprov.mof when the AD schema is stale.

For third-party providers, look in %ProgramFiles%\Windows Kits, or wherever the vendor dropped their MOFs. Dell's OpenManage puts them under C:\Program Files\Dell\SysMgt\oma\mof. Recompile those too.

Once done, restart the service:

net stop winmgmt && net start winmgmt

Then re-run the original WMI query that failed. If it works, you're done. If not, move on.

Cause 3: Namespace or DCOM Permission Issues

Less common but brutal to diagnose. If the account calling WMI can't access the namespace, some providers return 0x00001068 instead of the more honest 0x80041003 Access Denied. This shows up on hardened servers, in domain environments with restrictive GPOs, and after someone messes with the DCOM config.

Check the namespace ACL:

1. Open wmimgmt.msc as admin.
2. Right-click WMI Control (Local) → Properties → Security.
3. Expand Root and pick the namespace you're querying (usually root\cimv2).
4. Click Security and confirm your account has Execute Methods, Enable Account, and Remote Enable if it's a remote call.

For DCOM, run dcomcnfg, go to Component Services → Computers → My Computer → DCOM Config. Find Windows Management Instrumentation and confirm Launch and Activation permissions for the account you're using. I've seen group policy strip these on CIS-hardened builds.

Also check the firewall. Remote WMI needs RPC dynamic ports (TCP 135 inbound plus the RPC range). If you've locked down the RPC range in HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet, the firewall rule needs to match. Mismatched ranges cause WMI calls to fail in weird ways — sometimes 0x800706BA, sometimes 0x00001068.

Last resort for namespace issues: re-register the WMI service itself.

cd /d %windir%\System32\wbem
regsvr32 /s wbemsvc.dll
regsvr32 /s fastprox.dll
regsvr32 /s wbemprox.dll
regsvr32 /s wbemcomn.dll

Reboot after. Don't argue with it.

Quick Reference

One more thing. If you're getting 0x00001068 only from a specific application, and the WMI repo passes /verifyrepository clean, the problem is usually that app's provider, not WMI itself. Check the app's MOF and recompile that one file. Nine times out of ten it's a stale registration from a partial upgrade.