Fix CO_E_CONVERSIONFAILED 0x8001012E (Trustee String)

CO_E_CONVERSIONFAILED happens when Windows can't convert a Unicode trustee name to ANSI. Usually a permissions or legacy app issue. Here's the fix that actually works.

Quick answer: The error means a program tried to convert a Unicode user/group name into an older ANSI format during a permissions check, and it choked. The fastest fix is to run the app with administrative rights or repair the component's DCOM registration—but read on for the real workaround.

I've seen this exact error pop up in two places: old VB6 apps and custom COM components running under a service account. Last month a client's inventory software on Windows Server 2019 started throwing this after a domain user was renamed. Every login attempt failed with 0x8001012E. The app was trying to resolve a trustee (the fancy Windows term for a user or group) that no longer existed in the old format. Windows cares about security identifiers (SIDs), not names, but some legacy code still asks for the name in ANSI instead of Unicode. That mismatch is your problem.

Here's the thing—you rarely need to touch the registry for this. Most times it's a dead user account or a missing permission. But there are cases where a component's registration is corrupted. I'll walk you through both.

Fix 1: Clean Up the Dead Trustee

Open regedit (Win+R, type regedit, hit Enter).
Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList.
Look for keys like S-1-5-21-... that have a ProfileImagePath pointing to a user that no longer exists. If you see one, right-click and delete the key (back it up first—export it).
Also check HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon for a DefaultUserName that's stale.

That's the classic trigger. Renaming a domain user or deleting an old local account leaves orphaned entries. The app still tries to look up the old name, fails the conversion, and throws 0x8001012E.

Fix 2: Re-Register the COM Component

If the error comes from a specific DLL or EXE (check the event log for the source), re-register it:

regsvr32 /u "C:\Path\to\YourComponent.dll"
regsvr32 "C:\Path\to\YourComponent.dll"

Do this from an elevated command prompt (right-click Command Prompt, Run as administrator). If it's an out-of-process component, you might need to reinstall the app entirely—that's ugly but sometimes the only way.

Fix 3: The Service Account Workaround

If your app runs as a service, the service account's password might have expired or the account got removed from the "Impersonate a client after authentication" policy. Check that:

Open Local Security Policy (secpol.msc).
Go to Security Settings → Local Policies → User Rights Assignment.
Double-click Impersonate a client after authentication.
Add the service account or NETWORK SERVICE if missing.

I've fixed two different client systems just by doing this. The conversion failure often masks a permission problem in the background.

Alternative Fixes (When the Above Doesn't Work)

Check the system locale: The error can surface if your system uses a non-ANSI code page (like UTF-8 beta or Japanese). Go to Control Panel → Region → Administrative → Change system locale. Uncheck "Beta: Use Unicode UTF-8 for worldwide language support" if it's enabled. Reboot. That setting breaks a ton of legacy apps—had a client whose printing software refused to start because of it.
Update or replace the broken app: If it's a 20-year-old VB6 app, no amount of registry tweaks will save it. Look for a modern alternative or run it in a VM with the proper language pack.
Check for orphaned group SIDs: Run wmic useraccount get name,sid in a command prompt to list all SIDs. Cross-reference with your app's config files. If there's a mismatch, edit the config to use the correct SID instead of a name.

Prevention Tips

Never rename domain users without checking which apps reference them. Use group accounts if possible—they're easier to swap.
Keep your COM component registrations as part of the install script. When you update, always run the installer, not just copy files.
If you're writing software, stop using ANSI APIs. Use ConvertSidToStringSid instead of trustee strings—it's Unicode-native and avoids this whole mess.

That's the whole deal. Most of the time it's a stale user or a missing policy. If you still get 0x8001012E after trying these, you're looking at a deeper incompatibility—time to check with the vendor or migrate.