WMI Item ID Not Found (0x106A): 3 Fixes That Work

Cause 1: Corrupted or Stale WMI Repository

The most common reason you see 0x0000106A is a corrupted WMI repository. The repository is a database that stores metadata about all WMI classes and their properties. If it gets out of sync – say, after a Windows update or a crash – the provider may not recognize the item ID your script is asking for.

You'll often see this when running PowerShell commands that query Win32_* classes, or when a management tool like SCCM or a monitoring agent tries to pull data.

Fix: Recompile the WMI Repository

1. Open an elevated Command Prompt (right-click Command Prompt, select Run as administrator).
2. Type winmgmt /verifyrepository and press Enter. This checks the repository's consistency. The output will say either "WMI repository is consistent" or "WMI repository is inconsistent." If it's inconsistent, proceed.
3. Type winmgmt /salvagerepository and press Enter. This attempts to rebuild the repository from the existing files. It might take a few minutes, and you'll see no output until it finishes – that's normal.
4. After it completes, restart your computer. Once you're back, retest your script or query. The error should be gone.

If /salvagerepository doesn't work, then run winmgmt /resetrepository. This wipes the repository and rebuilds it from scratch. You'll lose custom WMI settings, but you won't lose system functionality.

Expected result: After either command, the repository is clean, and the error disappears for most users.

Cause 2: Missing or Incorrect MOF Files

The second most common cause is that the WMI provider's MOF (Managed Object Format) file wasn't properly installed or registered. MOF files define the classes and items that a provider exposes. If a program's installer left a partially registered MOF, the provider won't have the item ID your script requests.

This happens a lot after uninstalling and reinstalling a third-party application that has a WMI provider – like a backup tool or a hardware monitoring utility. You might see this error in the Application event log, usually with the provider name in the message.

Fix: Recompile the Specific MOF

1. Find the MOF file for the provider that's failing. You can get the provider name from the error log, or you can search C:\Windows\System32\wbem\ for *.mof files. Focus on ones that match the application or hardware vendor.
2. Open an elevated Command Prompt.
3. Run the MOF compiler with the path to that file. For example:
   

   mofcomp C:\Path\To\Your\provider.mof

4. You'll see output like "MOF file loaded successfully" or a compilation error. If it's successful, wait about 10 seconds for WMI to pick it up.
5. Restart the WMI service: net stop winmgmt then net start winmgmt. Or just reboot.

Expected result: The provider now recognizes the item ID, and the error stops.

Cause 3: WMI Security Permissions Blocking the Query

The third cause is trickier – it's a permissions issue. WMI has its own security layer. Even if the repository is fine and the MOF is registered, the account running the script may not have access to that specific WMI namespace or class. When access is denied, WMI sometimes throws this error instead of a clear "Access Denied."

You'll see this more often in enterprise environments where Group Policy restricts WMI access for standard users, or if you're running a PowerShell script as a service account with limited rights.

Fix: Grant WMI Permissions

1. Open wmimgmt.msc from Run (Win+R). This opens the WMI Management console.
2. Right-click "WMI Control (Local)" and select Properties.
3. Go to the Security tab.
4. Find the namespace your script is trying to access – usually root\cimv2 for most standard queries. Select it and click Security.
5. In the Group or user names list, add the account that's getting the error. Click Add, type the account name, and click OK.
6. In the Permissions for list, check the boxes for "Enable Account" and "Remote Enable" (if the script runs remotely) and at least "Read" for the security settings. If the script needs to write or invoke methods, check the corresponding boxes too.
7. Click Apply and OK, then close the console.

Expected result: The script now runs without error. If you're testing a service account, make sure to log off and log back in after changing permissions.

Quick-Reference Summary Table