CO_E_NOMATCHINGSIDFOUND (0X8001012F) fix: COM security trustee error

What's actually happening here?

Error 0x8001012F — officially CO_E_NOMATCHINGSIDFOUND — means the COM infrastructure received a user or group name it couldn't resolve to a security identifier (SID). What's happening under the hood is that somewhere in your COM permissions (launch, access, or activation) a trustee string points to a user or group that either no longer exists locally or whose SID can't be looked up on the current domain. This usually surfaces when you open Component Services snap-in (dcomcnfg) and try to modify any DCOM setting, or when a COM-based application (like certain versions of SQL Server, IIS, or backup software) fails to launch.

I've seen this most often after an account rename — you rename the built-in Administrator or a service account, and COM's ACL cache still references the old name. Also common after moving machines between domains or after deleting a domain user that had custom COM permissions assigned.

The fix path: start with the cheap wins, work up to the registry surgery.

The 30-second fix: Rebuild the default COM permissions

This won't work if you have custom per-app permissions, but for global level errors it kills the problem fast.

1. Open an admin Command Prompt or PowerShell.
2. Run dcomcnfg to open Component Services.
3. Navigate to Component Services > Computers > right-click My Computer > Properties.
4. Go to the COM Security tab.
5. Under Access Permissions, click Edit Limits. This is the machine-wide restriction, not the default.
6. Don't change anything here yet — just check if you see any entries with a yellow warning icon or a name like "Unknown User". If you do, remove them.
7. Click OK. Repeat for Launch and Activation Permissions > Edit Limits.
8. Now go to the Default buttons (below the Limits buttons). Same check — remove any orphaned entries.

Why this works: the "Edit Limits" dialog shows the machine-wide ACLs. If a stale trustee lives there, removing it clears the error for all COM applications. The reason step 3-5 matters is that COM checks the Limits list first — if it finds an unresolvable SID there, it fails before even looking at per-app settings.

The 5-minute fix: Find and purge the orphaned SID in the registry

If the GUI approach didn't work, the stale entry is hiding in a per-application ACL or in the registry's DefaultAccessPermission or DefaultLaunchPermission values. These are binary blobs — you can't read them easily, but you can nuke them and let Windows rebuild them fresh.

Backup your registry first. Seriously. Export the entire HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole key before touching anything.

1. Open Regedit as admin.
2. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole.
3. Look for these values:
   • DefaultAccessPermission
   • DefaultLaunchPermission
   • MachineAccessRestriction
   • MachineLaunchRestriction
4. If any of these exist and are not empty (size > 0 bytes), you have two options:
   • Delete them — Windows will regenerate defaults on next boot or COM service restart. Safe for most systems, but you lose any custom global COM permissions you intentionally set.
   • Export them — then edit the exported .reg file offline with a hex editor to remove the offending SID. This is advanced and error-prone.
5. After deletion, restart the COM+ Event System service (net stop COMSysApp then net start COMSysApp) or reboot.

What's actually happening: the binary SDDL in those registry values contains trustee names or SIDs. When COM tries to resolve them, it fails on one that's orphaned. Deleting the entire value forces COM to rebuild using the standard SYSTEM and Administrators entries. The reason you restart COMSysApp is that it hosts the COM infrastructure — without a restart, COM still caches the old broken ACLs in memory.

The 15+ minute fix: Forensic SID hunt with PowerShell and Process Monitor

This is for when you need to preserve custom COM permissions but still kill the error. You'll pinpoint which exact trustee string is broken and replace it with a valid one.

Step 1: Capture the error in Procmon

Download Process Monitor from Microsoft Sysinternals. Filter for Process Name = mmc.exe (or your COM-aware app) and Result = NAME_NOT_FOUND. Trigger the error by opening dcomcnfg or launching your failing app. Look for an event where the path mentions \SECURITY\ or \SAM\ — that's the failed SID lookup.

The detail will show the exact trustee name that couldn't be resolved. Write it down.

Step 2: Convert and replace

Open PowerShell as admin. If the broken trustee is a local user, run:

$brokenName = "YourOrphanedNameHere"
$users = Get-WmiObject Win32_UserAccount | Where-Object { $_.Name -eq $brokenName }
# If this returns nothing, the account is fully gone.
# If it returns a SID like S-1-5-21-..., the SID might still be valid but the name resolution is flaky.
# Try:
$sid = [System.Security.Principal.NTAccount]::new($brokenName).Translate([System.Security.Principal.SecurityIdentifier])
# If that throws, the name truly can't be resolved.

Now the fix: if you found the name in Procmon, it's likely a stale entry in a per-application ACL inside the AppID registry key. Navigate to:

HKEY_CLASSES_ROOT\AppID\{YourAppGUID}

Look for values named LaunchPermission or AccessPermission (binary type). These are per-application overrides. You can't easily edit them by hand, but you can delete them — the app will then inherit from the machine-wide defaults. If you need to preserve them, use the Get-ACL / Set-ACL cmdlets on the COM object via PowerShell's COM automation interface, but that's a separate deep dive.

Step 3: Last resort — recreate the missing account

If the broken trustee was a local user that was deleted, you can recreate it with the same name and the SID will usually match (if the RID space hasn't been reused). For domain users, rejoin the domain or re-add the user group. This is rare but I've had it happen with the IUSR account on IIS servers where someone deleted and recreated it with a different SID.

That's the full chain. Start with dcomcnfg cleanup, escalate to registry value deletion, and only go full forensic if you're customizing COM permissions heavily.