Fix CO_E_NOMATCHINGNAMEFOUND (0X80010131) Trustee Error

You're setting up a DCOM application or tweaking permissions in Component Services, and bam — you get error 0X80010131 with the message "Unable to find a trustee name that corresponds to a security identifier provided by the user." This usually happens right after you click "Add" or "Apply" when trying to grant permissions to a user or group in the COM Security dialog. I've seen it most often on machines that were migrated from an old domain to a new one, or when someone deleted a user account and then tried to reuse the same SID-based permission entry.

What's actually going on?

The short version: Windows stores permissions for COM objects using security identifiers (SIDs), not display names. When you add a user to a COM security list, Windows tries to look up the friendly name (like "DOMAIN\jsmith") from the SID. If that lookup fails — because the account was deleted, renamed, or the domain trust broke — you get this error. The SID is orphaned. It's like a key that doesn't fit any lock anymore.

The real culprit is almost always a stale permission entry left over from a previous account. Windows can't translate the SID back to a name, so it throws the error when you try to modify or view the list. But here's the kicker: sometimes the error happens even when you're just trying to add a new user. That's a sign the COM security cache is corrupted or a previous entry is blocking the write.

The fix: clean up orphaned SIDs

You've got two paths here. The first one works 90% of the time. The second one is for when the first one fails.

Path 1: Use Component Services (the easy way)

1. Press Win + R, type dcomcnfg, and hit Enter.
2. In the Component Services window, expand Component Services > Computers > right-click My Computer and select Properties.
3. Go to the COM Security tab.
4. Under Access Permissions, click Edit Default or Edit Limits (depends on where you got the error). A window with the list pops up.
5. Look for any entry where the Name column shows a SID (starts with S-1-5...) instead of a friendly name like "Everyone" or "Administrators". Those are your orphans.
6. Select each orphaned entry one by one and click Remove.
7. Repeat the same for Launch and Activation Permissions — also check both Default and Limits if needed.
8. Click OK on all dialogs. Close Component Services.
9. Restart the machine. Not just the service — do a full restart.

After restart: Try your original action again. If the error is gone, you're done. If it's still there, move to Path 2.

Path 2: Registry edit (when Component Services won't let you in)

Sometimes Component Services itself won't even let you open the permissions list — it throws the same error. That means the corruption is deep. You'll need to nuke the entries manually.

1. Open Registry Editor (Win + R, type regedit, press Enter).
2. Navigate to HKEY_CLASSES_ROOT\AppID\{your-appid-guid}. If you don't know the AppID, you can find it by looking at the error log in Event Viewer (look for source "DCOM" with event ID 10016 or 10010).
3. On the right side, look for values named AccessPermission or LaunchPermission. These are binary blobs.
4. Right-click each one and select Delete. Confirm.
5. Also check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\AppDefault\AccessPermission and LaunchPermission — delete those too if they exist. These are machine-wide defaults.
6. Close Registry Editor. Restart the machine.

Note: When you delete these values, Windows will rebuild them with default permissions on next boot. That's fine — you can reconfigure your custom permissions afterward without the error.

What if it still fails?

Try these in order:

• Check if the account exists. Open a Command Prompt as admin and run net user /domain. If it says "The user name could not be found," you're trying to use a deleted account. Create a new one or use a different account.
• Verify domain trust. If you're on a domain, run nltest /domain_trusts to see if the domain is reachable. A broken trust will cause all SID lookups to fail.
• Rebuild the COM security cache. Stop and restart the DCOM Server Process Launcher service (RpcSs). But be careful — this service is critical. Do it from Services.msc, not by killing it. Reboot after.
• Last resort: Use a tool like Process Monitor from Sysinternals. Filter by the DCOM process (like svchost.exe with DCOMLaunch or dllhost.exe) and look for the exact SID that's failing. Then search the registry for that SID and remove its permission entries.

I've seen this error take down a whole print server once because a deleted domain admin account was left in the COM permissions. Don't overthink it — most of the time it's just a stray orphaned SID. Remove it, reboot, move on.