WMI Already Disabled Error 0X00001074 – Real Fix
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\CIMOMthat'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:
- Stop the WMI service:
net stop winmgmt - Rename the repository folder:
ren C:\Windows\System32\wbem\Repository Repository.old - Restart the service:
net start winmgmt— Windows auto-creates a fresh repository from the MOF files. - Run
winmgmt /verifyrepositoryto 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\wbemfolder must haveSYSTEMandAdministratorswith Full Control. Reset withicacls 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 *.moffrom an admin cmd inC:\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?