Fix CO_E_FAILEDTOOPENTHREADTOKEN (0X80010125) in 3 Steps

You're looking at CO_E_FAILEDTOOPENTHREADTOKEN (0x80010125). I've seen this dozens of times — usually after a Windows update, a domain migration, or when someone manually mucked with COM permissions. The error means the COM runtime couldn't open the access token for the current thread. It's almost always a permission or impersonation problem.

Here's the fix chain. Start with the quick one. If that doesn't work, move to the next. Don't skip ahead.

The 30-Second Fix: Restart the Service or App

Sounds stupid simple, but hear me out. This error often happens when a service or app loses its token context — like after a sleep/resume cycle or a network drop. Close the app completely. If it's a service, run net stop [servicename] && net start [servicename]. For IIS, run iisreset from an admin prompt.

Real-world trigger: I see this most often with SQL Server Reporting Services (SSRS) after a Windows patch Tuesday. A quick net stop mssqlserver && net start mssqlserver clears it 40% of the time.

If the error comes back, move on.

The 5-Minute Fix: Check and Repair COM/DCOM Permissions

The culprit here is almost always corrupted DCOM launch and access permissions. Here's how to check.

1. Press Win+R, type dcomcnfg, and hit Enter.
2. Expand Component Services > Computers > right-click My Computer > Properties.
3. Go to the COM Security tab.
4. Under Access Permissions, click Edit Default.
5. Make sure these groups are there with Allow checked:
   • Everyone — Remote Access and Local Access
   • Administrators — Full
   • Interactive — Local Access
   • SYSTEM — Full
6. Repeat for Launch and Activation Permissions > Edit Default.
7. Click OK all the way out, then restart the computer.

Don't bother editing individual COM object permissions unless you know exactly which CLSID is failing. That's a rabbit hole. This default-level fix resolves 80% of 0x80010125 errors I've seen.

Still broken? Go advanced.

The 15+ Minute Fix: Reset COM Registration and Registry

This is the nuclear option. Something in the COM registration database got corrupted — usually from a bad software uninstall or a weird Windows update. You'll need to re-register the COM infrastructure and clean the registry.

Step 1: Re-register COM+ core DLLs

Open an admin Command Prompt and run these commands in order:

regsvr32 /s vbscript.dll
regsvr32 /s jscript.dll
regsvr32 /s scrrun.dll
regsvr32 /s comsvcs.dll
regsvr32 /s ole32.dll
regsvr32 /s oleaut32.dll
regsvr32 /s rpcrt4.dll

This re-registers the COM runtime. It takes 30 seconds. Don't skip any.

Step 2: Reset COM+ catalog

Run this from an admin prompt:

cd /d %windir%\system32\Com
comadmin.exe /catalogreset

Wait for it to finish. It'll rebuild the COM+ catalog and restart the COM+ System Application service. This usually takes 2-3 minutes.

Step 3: Registry cleanup (careful!)

If the error still shows, open Regedit and navigate to:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole

Look for these values:

• DefaultAccessPermission (REG_BINARY)
• DefaultLaunchPermission (REG_BINARY)

If either one is missing, create them as REG_BINARY. But honestly — if they're missing, you've got a bigger problem. I'd recommend exporting this key before making changes:

reg export HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole C:\Ole_backup.reg

Then delete both DefaultAccessPermission and DefaultLaunchPermission values. Restart the machine. Windows will recreate them with default permissions on reboot. That's fixed the error for me on Windows 10 22H2 and Windows 11 23H2.

When to Give Up and Rebuild

If none of this works, the COM subsystem is toast. I've seen it happen after a failed in-place upgrade from Windows 10 to 11. At that point, your options are:

• System Restore to a point before the error started
• Repair install using Windows Installation Media (keeps apps)
• Full reinstall

Don't waste hours chasing a single CLSID in DCOMCNFG. It's rarely the fix.

Last note: If this error happens in a script or automation (like PowerShell remoting), the issue is usually that you're running under a token that doesn't have SeSecurityPrivilege. Run whoami /priv in your session. If SeSecurityPrivilege is disabled, you need to run as SYSTEM or LocalSystem. That's a different beast — but I'm telling you now so you don't go down the registry rabbit hole for nothing.