ERROR_WMI_TRY_AGAIN 0X0000106B: Causes and Fix

WMI threw a transient error and wants you to retry the call. Usually it's a corrupted WMI repository, a dead provider, or an overloaded RPC stack. Fix the repo, then restart the service.

Quick answer: Retry the WMI call once — if 0X0000106B comes back, run winmgmt /verifyrepository, then salvage or rebuild the repo, and restart the Winmgmt service.

ERROR_WMI_TRY_AGAIN is WMI's way of saying "that wasn't fatal, but I couldn't finish — call me again." It's a transient-looking error code that hides a real problem. You'll see it most often on servers that have been up for 200+ days, on boxes that just took a botched cumulative update, or on machines where a third-party provider (antivirus, backup agent, Dell OpenManage, HP Insight) is hanging onto a namespace and never releasing it. The Windows Management Instrumentation service hands the request off to a provider, the provider stalls or dies, and the WMI core returns 0x106B instead of something useful. Retrying works maybe 10 percent of the time. The other 90 percent, your repository is dirty or a provider is wedged, and no number of retries will clear it.

Don't confuse this with WBEM_E_NOT_FOUND (0x80041002) or WBEM_E_FAILED (0x80041001). Those are hard failures. 0x106B is the retry-later cousin, and it usually shows up in event logs under Microsoft-Windows-WMI-Activity/Operational, Event ID 5857 or 5858, with the provider CLSID spelled out. That CLSID is your starting point.

Before you touch anything

Open an elevated command prompt. Everything below needs admin. Also grab the provider CLSID from the WMI-Activity log so you know what's actually failing — rebuilding a repo on a clean box wastes 20 minutes and fixes nothing.

wevtutil qe Microsoft-Windows-WMI-Activity/Operational /c:20 /rd:true /f:text

Scan for the CLSID and the namespace. If it's root\cimv2 with a Microsoft CLSID, it's almost always repo corruption. If it's a third-party namespace like root\HP or root\Dell, the agent's the problem — reinstall it instead of shotgun-rebuilding WMI.

Fix steps

Retry the call once. If you're scripting it, wrap it in a single retry with a 2-second sleep. That's it. Two retries is fine. Ten retries in a loop is how you turn a hiccup into a hung service.
```
Get-WmiObject -Class Win32_OperatingSystem -ErrorAction Stop
```
If it fails again with 0x106B, move on.
Verify the repository. This tells you if the repo is actually corrupt or just locked.
```
winmgmt /verifyrepository
```
You'll get either WMI repository is consistent or WMI repository is inconsistent. Consistent means skip to step 4. Inconsistent means carry on.
Salvage the repo. This is the smaller hammer. It rebuilds the index without nuking registered providers. Takes 30 seconds to 2 minutes. Works maybe 60 percent of the time on corruption cases.
```
winmgmt /salvagerepository
```
Don't skip /verifyrepository before this — you want to know if it worked.
Reset the repo (the bigger hammer). Only if salvage failed. This drops your non-default namespaces. Third-party agents will need reinstalling. Back up first:
```
net stop winmgmt
cd /d %windir%\system32\wbem
ren Repository Repository.old
net start winmgmt
```
Windows rebuilds the default repo on service start. Reboot after. If a provider complains about a missing namespace, reinstall that agent.
Restart the WMI service. Even if you didn't rebuild, a stale RPC binding can cause 0x106B. A clean restart clears it.
```
net stop winmgmt /y
net start winmgmt
sc query winmgmt
```
Confirm it's RUNNING, not START_PENDING. If it hangs at START_PENDING past 60 seconds, you've got a broken provider dependency, not a service problem. Check the System log for DCOM 10016 or 10010 errors.
Kill the offender on the WMI-Activity CLSID. Look up the CLSID under HKLM\SOFTWARE\Classes\CLSID\{...} and check InprocServer32. That DLL is your provider. If it's from Symantec, Trend, Veeam, or an out-of-date OEM agent, update or uninstall it. Windows Defender ASR rules on Server 2019+ will also flag legacy providers — check Get-MpPreference | select AttackSurfaceReductionRules_Ids if you've hardened the box.
Test the call again. Same command from step 1. If it returns a Win32_OperatingSystem object, you're done.

If that doesn't work

Check DCOM permissions. WMI rides DCOM. If someone tightened permissions on the SYSTEM or Performance Log Users groups, you'll get 0x106B on calls that used to work. Run dcomcnfg, expand Component Services, and verify DCOM Config defaults haven't been mangled.
Look at RPC. A stalled RPC endpoint mapper bleeds into WMI. Check sc query rpcss and sc query winmgmt together. If RPCSS is wedged, restart both — but know that on a domain controller that's a real outage.
Reboot. I know. But if you've salvaged, restarted the service, and still get 0x106B, the provider's DLL is loaded in a stuck worker thread. Only a reboot will unload it. Schedule it — don't do it during business hours on a prod box.
DISM and SFC. If the CLSID resolves to a Microsoft provider DLL in %windir%\system32\wbem, run:
```
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow
```
Corrupted WMI DLLs from a half-applied update are a classic cause on Server 2016 after KB500x updates.

Stop it from coming back

Don't let third-party providers install into WMI without grooming. Every monitoring agent, backup tool, and endpoint security product wants its own namespace, and every one of them is a potential 0x106B. Audit what's registered:

Get-WmiObject -Namespace root -Class __Namespace | Select Name

If you see namespaces you don't recognize, investigate before they bite you at 3 AM. And patch your OEM agents on a schedule — HP and Dell both shipped WMI providers with known leaks in 2019-era builds that filled the repo over months. That's the origin story for most of the 0x106B tickets I've worked.

One more thing: if you're calling WMI from a script on a timer, add exponential backoff on 0x106B specifically. Hammering a struggling WMI service is how you turn a transient error into a service crash.