Error 0x0000106E: WMI Already Enabled — Fix the Double Registration

Seeing error 0x0000106E is annoying because nothing obvious is broken — until you try to create a WMI event filter or subscription and the system tells you it's already there. The real issue: something registered the same WMI object twice, and WMI refuses to create a duplicate.

Quick Fix: Delete the Duplicate WMI Subscription

The fastest way to resolve this is to remove the duplicate event filter, consumer, or binding. You can do this in two ways. I prefer PowerShell because it's faster once you know the commands.

Using PowerShell

1. Open PowerShell as Administrator.
2. List all permanent event subscriptions:

   Get-WmiObject -Namespace root\subscription -Class __EventFilter

   Get-WmiObject -Namespace root\subscription -Class __EventConsumer

   Get-WmiObject -Namespace root\subscription -Class __FilterToConsumerBinding

3. Look for duplicates — same Name, same Query, same CreatorSID. If you see two objects with identical properties, note their __RELPATH.
4. Delete the duplicate (keep the original):

   $filter = Get-WmiObject -Namespace root\subscription -Class __EventFilter -Filter "Name='YourFilterName'"
   # If you get multiple results, pick the one you want to delete
   $filter[0] | Remove-WmiObject

5. Repeat for the consumer and binding if they have duplicates.

Using WMI Explorer (GUI)

1. Download and run WMI Explorer from Microsoft (free, not included in Windows by default).
2. Connect to root\subscription namespace.
3. Navigate to __EventFilter, __EventConsumer, and __FilterToConsumerBinding.
4. Sort by Name. Any name appearing twice is your culprit. Right-click the duplicate and select Delete.
5. Do the same for the matching consumer and binding if they have duplicates too.

Why This Happens

WMI doesn't allow two objects with the same Name and CreatorSID in the same namespace — that's the core constraint. The real trigger: a script, management tool (like SCCM, Nagios, or a custom monitoring script), or even a Windows feature (like Remote Event Log Management) ran Register-WmiEvent or created a permanent event subscription via WMI API twice. The first registration works fine. The second call fails with 0x0000106E because the object already exists.

What's actually happening here is that the WMI repository (%windir%\System32\wbem\Repository) already holds the registration. The error code 0x0000106E maps to WBEM_E_ALREADY_EXISTS in the WMI provider internals — it's not a corruption, it's a collision.

Less Common Variations

You might hit this error in these specific scenarios:

• Windows Server 2016+ with Active Directory Certificate Services — a misconfigured CA can double-register WMI event filters for certificate enrollment events. Check root\subscription for filters named SCEP_CertRequest.
• System Center Operations Manager (SCOM) agent — if the agent is reinstalled without full uninstall, it can duplicate its health service WMI subscriptions. Look for filters with Microsoft in the name.
• Custom PowerShell scripts with infinite loops — I've seen a faulty script that registered the same event query inside a while ($true) loop. Each iteration would fail with 0x0000106E after the first.
• Group Policy Software Installation — if a WMI filter-based GPO is applied to a machine multiple times (e.g., loop processing), it can create duplicate permanent subscriptions.

Prevention

1. Wrap WMI registration in a check — before calling Register-CimIndicationEvent or creating a __EventFilter, query if it exists first. Example:

   $existing = Get-WmiObject -Namespace root\subscription -Class __EventFilter -Filter "Name='MyFilter'"
   if (-not $existing) {
       # create filter
   }

2. Use a unique name per subscription — include a GUID or timestamp in the Name property to avoid collisions.
3. Clean up on script exit — if you're creating temporary subscriptions, delete them when done using Remove-WmiObject or the consumer's Delete() method.
4. Monitor WMI logs — check Event Viewer > Applications and Services Logs > Microsoft > Windows > WMI-Activity for repeated registration attempts. A pattern of errors from the same process ID is a red flag.
5. Don't blindly re-run monitoring agent installers — always uninstall the old agent first, or use the agent's built-in repair option instead of installing over top.

That's it. The fix is straightforward — find the duplicate, delete it. The real work is figuring out what created it in the first place so it doesn't come back.