0XC0000302: WMI already disabled — what's really happening

When does this error show up?

You'll see 0XC0000302 (which maps to STATUS_WMI_ALREADY_DISABLED) when something tries to disable a WMI event collection or subscription that's already been disabled. Typical triggers:

• A monitoring tool (Nagios, PRTG, SCOM) polls a WMI class and then tries to clean up the same subscription twice.
• A custom script calls SWbemSink.Cancel() on an already-cancelled subscription.
• Two separate WMI consumers run the same event filter — one disables it, then the second tries again because it doesn't know the state changed.

The error code is 0XC0000302. It's not a corruption or permission problem. It's a state management issue.

Why the root cause is a handle leak, not a WMI failure

WMI event subscriptions are reference-counted internally. When you create a temporary event consumer (like a script subscribing to __InstanceCreationEvent), WMI assigns it a handle and starts delivering events. When you cancel or disable that subscription, WMI decrements the reference count. If the count reaches zero, it removes the subscription entirely.

The problem: some tools or scripts don't track whether they've already disabled a subscription. They call the disable routine twice. On the second call, WMI sees no active subscription to disable — it returns STATUS_WMI_ALREADY_DISABLED. That's the 0xC0000302.

This isn't a WMI corruption. It's a race condition or a bad pattern in the consumer code. The fix is almost never to repair WMI — it's to close the duplicate handle or to reset the subscription cleanly.

Step-by-step fix

Step 1: Identify which subscription is stuck

Open PowerShell as Administrator. Run this to list all permanent event subscriptions:

Get-WmiObject -Namespace root\subscription -Class __EventFilter | Format-List Name, Query
Get-WmiObject -Namespace root\subscription -Class __EventConsumer | Format-List Name
Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Format-List *

If you have a temporary subscription (created by a script), it won't show here. The error likely came from a script that didn't clean up properly. Check for orphaned SWbemSink objects in the process that threw the error.

Step 2: Cancel the subscription cleanly

If the subscription is permanent, delete the binding and the consumer:

$binding = Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding | Where-Object { $_.Consumer -match "YourConsumerName" }
$binding.Delete()

$consumer = Get-WmiObject -Namespace root\subscription -Class __EventConsumer | Where-Object { $_.Name -eq "YourConsumerName" }
$consumer.Delete()

$filter = Get-WmiObject -Namespace root\subscription -Class __EventFilter | Where-Object { $_.Name -eq "YourFilterName" }
$filter.Delete()

If the subscription is temporary (created in a script), you can't delete it via WMI — you need to kill the script's process or ensure the script cancels the sink properly. The correct pattern in VBScript:

Set sink = WScript.CreateObject("WbemScripting.SWbemSink", "Sink_")
' ... subscribe ...
sink.Cancel()   ' call this exactly once
Set sink = Nothing

In PowerShell, use Register-CimIndicationEvent with -Action and then Unregister-Event.

Step 3: Restart the WMI service (last resort)

If you can't find the subscription and the error keeps happening, force a reset. This will break any running WMI-dependent apps for a moment:

net stop winmgmt /y
net start winmgmt

The /y flag stops dependent services (like SMS Agent Host). After restart, all temporary subscriptions are gone. Permanent ones reload from the repository.

Step 4: Check for competing consumers

If the error returns after restart, you've got two independent processes both trying to subscribe and cancel the same event. Use Process Monitor to see which process is making the duplicate Cancel call. Filter on Path contains \WMI and look for IRP_MJ_CREATE on the WMI GUID.

Real story: I saw this once when a backup agent and an AV scanner both subscribed to the same __InstanceModificationEvent for registry keys. Their cleanup routines stepped on each other. The fix was to configure the AV scanner to use a different WMI namespace — a dumb workaround, but it worked.

What to check if it still fails

• Is the error coming from a third-party driver? Some drivers register WMI event providers. A buggy driver can double-disable its own subscription. Update the driver.
• Are you using WinRM? Remote WMI calls through WinRM sometimes create duplicate subscriptions under the root\cimv2 namespace. Check for __Win32Provider entries with odd names.
• Do you have two scripts running with the same sink variable name? In VBScript, global variables persist. Two scripts running in the same host (like cscript.exe) can share a sink object. Run each in its own cscript.exe process.
• Check the WMI log: %windir%\system32\wbem\logs\wbemcore.log often has a line like DisableEvent failed with 0xc0000302 — it tells you the provider GUID. That GUID maps to a specific DLL. Use mofcomp to check which provider registered it.

Bottom line: this error is almost never a WMI corruption. It's a consumer that doesn't know when to stop. Find the duplicate, kill it, and move on.