Fix CO_E_WRONGTRUSTEENAMESYNTAX (0x8001012C) in Windows

You hit CO_E_WRONGTRUSTEENAMESYNTAX (0x8001012C) and Windows is blocking something—usually a COM+ application, a .NET service, or a DCOM call—because it can't parse a trustee name in an access control entry. It's frustrating, but the fix is straightforward once you know where to look.

The quick fix: Clear COM+ roles in Component Services

Open Component Services (run dcomcnfg as administrator). Navigate to Component Services > Computers > My Computer > COM+ Applications. Find the application that's throwing the error—often it's .NET Utilities or IIS Admin Service—and expand it, then Roles. If you see any roles listed, right-click and Delete them. The error usually goes away immediately.

The reason this works: each role in COM+ has a trustee name (a security principal like a user or group). If that principal was deleted from Active Directory or the local SAM, or if its SID got corrupted during a domain migration, COM+ can't resolve it. It throws 0x8001012C instead of gracefully ignoring it. Clearing the roles removes the dangling references.

dcomcnfg # then navigate manually

If that doesn't work: Re-register the COM+ application

Sometimes the roles are empty but the application's security descriptor itself is busted. Unregister and re-register it:

Open an elevated Command Prompt.
Run regsvr32 /u [path-to-dll] for the offending COM+ component (e.g., regsvr32 /u C:\Windows\System32\mscoree.dll).
Then regsvr32 [path-to-dll] (without /u).

This rebuilds the COM+ catalog entries. It's a blunt instrument, but it fixes cases where the security descriptor's ACL entries reference SIDs that no longer exist.

Why the error happens

Under the hood, COM+ uses Windows Security Descriptors (SDs) to control access. Each SD has a list of trustees—users, groups, or well-known SIDs (like SYSTEM or NETWORK SERVICE). The trustee name syntax is Domain\Name or a raw SID string (S-1-5-21-...). If the name contains invalid characters (like an extra space, a missing backslash, or a non-ASCII character that got mangled), or if the referenced account simply doesn't exist, the LookupAccountName or LookupAccountSid function fails, and COM+ replies with CO_E_WRONGTRUSTEENAMESYNTAX.

I've seen this most often after a domain rename, a migration from Windows 7 to 10/11, or when someone deleted a service account that was used by a COM+ application. The registry entries in HKEY_CLASSES_ROOT\AppID\{GUID} still reference the old account name.

Less common variations

Three edge cases I've run into:

1. Corrupted SID in the registry

Check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\COM3\APPID. Look for the GUID matching your errored application. Under AccessPermission or LaunchPermission, you'll see binary data. Decode it with a tool like sc.exe sdshow or SetACL.exe. If you see a trustee name like O:SYG:SYD:(A;;CC;;;S-1-5-21-... and that SID doesn't exist on your system, you've found the culprit. Export the key, delete the offending ACE's bytes, and re-import.

2. .NET Framework trust level mismatch

If the error comes from a .NET service (event log shows .NET Runtime as source), the issue is often the trustLevel in machine.config. Open C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\machine.config and check the <trust> element. If it's set to Full but the COM+ application expects High, change it and recycle the app pool.

3. IIS application pool identity

IIS 10 on Windows Server 2019/2022 sometimes triggers this when an application pool runs as ApplicationPoolIdentity but the COM+ component's security descriptor only allows NETWORK SERVICE. Switch the pool identity to NetworkService temporarily to test.

# Check current app pool identity (PowerShell as admin)
Get-IISAppPool -Name "DefaultAppPool" | Select-Object -ExpandProperty processModel

Prevention

Three rules to avoid seeing this again:

Never delete a service account that's used in COM+ without first removing it from all COM+ roles and the registry's AppID entries.
Use Group Policy to set COM+ application roles centrally instead of manually assigning users. That way when an account is removed, the policy updates automatically.
Audit your COM+ applications quarterly with a script that enumerates all roles under dcomcnfg and checks if the trustee names resolve. PowerShell's Get-WmiObject -Namespace root\CIMV2 -Class Win32_DCOMApplication is a decent start.

That's the whole story. The error is annoying but rarely deeper than a stale trustee reference. Clear the roles, re-register if needed, and move on.