0X00001074

WMI Already Disabled Error 0X00001074 – Real Fix

Windows Errors Intermediate 👁 0 views 📅 May 28, 2026

This error pops up when Windows Management Instrumentation can't enable a data block or notification because it's already off. Here's how to reset it without rebuilding the whole WMI store.

When You'll See This Error

You're setting up a new monitoring tool—maybe PRTG, maybe a custom PowerShell script that polls WMI for disk stats. You run a query like Get-WmiObject Win32_LogicalDisk and get nothing useful. Then you check the Application Event Log and find event ID 10 with source WMI, showing ERROR_WMI_ALREADY_DISABLED (0X00001074). Or you're trying to subscribe to an event notification via Register-WmiEvent and it throws that exact hex.

I've seen this mainly on Windows 10 and 11 machines where a third-party tool or a group policy shoved a WMI provider into a disabled state. Had a client last month whose backup software did this after a failed update—blanketed half the WMI namespaces with disabled flags.

What's Actually Happening

WMI keeps a registry of which data blocks (like classes) and event notifications (like subscription filters) are active. When something tries to enable an already-disabled block, WMI doesn't just let you toggle it back—it throws 0X00001074. The root cause is almost always a corrupted WMI repository or a provider that's been manually or programmatically disabled.

Common triggers:

  • An application that disabled WMI components during uninstall (yes, bad uninstallers do this)
  • Group Policy that disables specific WMI providers for security
  • A registry key under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM that's got stale entries
  • A disk full or NTFS permission glitch that corrupted the repository

Step-by-Step Fix

Step 1: Identify the Disabled Component

Open an admin PowerShell or Command Prompt. Run:

wmic /namespace:\\root\cimv2 path __Class get Name | findstr /i disabled

If nothing shows, the block might be an event filter. Check the subscription store:

Get-WmiObject -Namespace root\subscription -Class __EventFilter

Look for any filter with Enabled set to False. If you find one, that's your culprit.

Step 2: Re-enable the Block (Fastest Fix)

If you know the exact class or filter name, use WBEMTEST (Microsoft's WMI tester). Press Win + R, type wbemtest, hit Enter. Connect to root\cimv2 or the appropriate namespace. Query for the disabled object: SELECT * FROM __Class WHERE Name='YourClassName'. Double-click the result, set the Enabled property to TRUE, and save.

Or do it in PowerShell:

$filter = Get-WmiObject -Namespace root\subscription -Class __EventFilter -Filter "Name='YourFilterName'"
$filter.Enabled = $true
$filter.Put()

That usually works right away. Restart the Winmgmt service: net stop winmgmt && net start winmgmt

Step 3: Reset the Repository (If Step 2 Fails)

Sometimes the repository is so corrupted that WBEMTEST changes don't stick. Here's the real fix—this is what I do when I'm in a hurry:

  1. Stop the WMI service: net stop winmgmt
  2. Rename the repository folder: ren C:\Windows\System32\wbem\Repository Repository.old
  3. Restart the service: net start winmgmt — Windows auto-creates a fresh repository from the MOF files.
  4. Run winmgmt /verifyrepository to confirm consistency.

This is drastic, but it works. You'll lose custom WMI data (like some software's instrumentation), but the core stuff comes back clean. Had a client whose whole print queue died because of this—reset the repo, everything came back to life.

Step 4: Check for Group Policy

If the error returns after reboot, check Group Policy. Run gpedit.msc (Pro/Enterprise) and go to Computer Configuration > Administrative Templates > Windows Components > Windows Management Instrumentation (WMI). Look for any policy that disables WMI providers. Set them to Not Configured.

On non-Pro Windows, check the registry: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\WBEM. If it exists, delete it or set values to 0.

What to Check If It Still Fails

If you done all that and the error's still there, you're looking at a deeper problem:

  • Disk corruption: Run chkdsk /f C: and reboot. A bad sector on the System32 folder can corrupt the MOF files.
  • File permissions: The C:\Windows\System32\wbem folder must have SYSTEM and Administrators with Full Control. Reset with icacls C:\Windows\System32\wbem /reset /t.
  • Bad provider: A third-party provider (like from an old antivirus or VPN) might be stuck in a disabled state. Uninstall that software, then re-register all providers with mofcomp *.mof from an admin cmd in C:\Windows\System32\wbem.

If you're still stuck after that, I'd rebuild the WMI repository from scratch. But honestly, 95% of the time, step 2 or step 3 solves it.

Was this solution helpful?