Fix CO_E_FAILEDTOGETTOKENINFO 0X80010126

Happens when COM can't read user info from the access token. Often in Office apps or PowerShell automation. Fix by checking app identity or token permissions.

You're running a script or an app that talks to COM — maybe Excel automation in PowerShell, an IIS web app calling an Office COM object, or a legacy VB6 tool. Suddenly it throws 0X80010126 with CO_E_FAILEDTOGETTOKENINFO. The exact moment: when the COM call tries to find out who you are — your username, group memberships — but the token is empty or damaged.

What's actually happening here is that COM uses your access token to figure out your identity and permissions. If the token is missing key info (like the user SID or group list), COM can't complete the call. This usually happens when the process runs under a service account, a network service, or an anonymous session. IIS app pools running as ApplicationPoolIdentity are a common trigger — their tokens are stripped of user info for security, which breaks COM.

What Causes This

Impersonation level too low. If you call COM from a thread that only has SecurityImpersonation or Anonymous, the token won't carry enough data. COM needs Identification at minimum.
Process runs under a virtual account. IIS app pool identities, NETWORK SERVICE, or LOCAL SERVICE accounts often have restricted tokens. They can't pass user info to COM.
COM+ application identity mismatch. A COM+ component configured to run as a specific user, but that user doesn't have proper token privileges (like SeBatchLogonRight).

Fix It Step by Step

Step 1: Check Your App's Process Account

Open Task Manager, find your process, right-click and go to Details. Look at the user name column. If it says NETWORK SERVICE, LOCAL SERVICE, or IIS APPPOOL\YourPoolName, that's your issue. These accounts lack proper user tokens.

Fix: Change the process to run under a real user account. For IIS:

Open IIS Manager, select your app pool.
Go to Advanced Settings → Process Model → Identity.
Set it to NetworkService or a dedicated domain account. ApplicationPoolIdentity won't work for COM automation.
Recycle the app pool.

Step 2: Adjust COM Security for Your Account

If the account is correct, the COM security might block it.

Run dcomcnfg as administrator.
Go to Component Services → Computers → My Computer → right-click → Properties.
Under COM Security tab, click Edit Limits in both Access Permissions and Launch and Activation Permissions.
Add your user account (or NETWORK SERVICE if that's what you use) and give it Local Access, Remote Access, Local Launch, Remote Launch, Local Activation, Remote Activation — all of them.
Apply and reboot.

Note: Some COM objects (like Office) require you to set permissions on the specific component, not just My Computer. Find its CLSID in the registry under HKEY_CLASSES_ROOT\CLSID\{your-guid} and check there.

Step 3: Give the Account Necessary Privileges

The token needs SeBatchLogonRight and SeInteractiveLogonRight to work properly with COM. Even for service accounts.

Run secpol.msc as admin.
Go to Local Policies → User Rights Assignment.
Find Log on as a batch job and add your account.
Find Log on locally and add your account.
Run gpupdate /force in command prompt and reboot.

Step 4: If Using Office COM, Set DCOM Identity

Office COM objects (like Excel.Application) are signed. They refuse calls from non-interactive accounts. The fix is to tell DCOM to run them as a specific user.

In dcomcnfg, expand Component Services → Computers → My Computer → DCOM Config.
Find Microsoft Excel Application (or Microsoft Word Application, etc.).
Right-click → Properties → Identity tab.
Select This user and enter a real account (not NETWORK SERVICE).
Apply, then restart the COM process: run taskkill /f /im WINWORD.EXE or taskkill /f /im EXCEL.EXE.

Step 5: Last Resort — Use a Registry Workaround

If nothing works, you can force COM to accept tokens from non-interactive accounts. But this weakens security — use only on isolated machines.

reg add "HKLM\SOFTWARE\Microsoft\Ole" /v "EnableDCOM" /t REG_SZ /d "Y" /f
reg add "HKLM\SOFTWARE\Microsoft\Ole" /v "LegacyAuthenticationLevel" /t REG_DWORD /d 2 /f
reg add "HKLM\SOFTWARE\Microsoft\Ole" /v "LegacyImpersonationLevel" /t REG_DWORD /d 3 /f

These set authentication to Connect and impersonation to Identify. Reboot after.

Still Fails? Check These

Event Viewer — Go to Windows Logs → System, filter by source DCOM. The error ID 10010 or 10005 tells you which CLSID failed. Search that CLSID in the registry to find the app.
Antivirus — Some security software blocks COM calls from low-privilege tokens. Temporarily disable it to test.
Corrupted Token — Run whoami /all in an admin cmd. If it shows no groups or missing SIDs, your user profile is damaged. Create a new Windows user and test from there.

The real fix is almost always Step 1 or Step 4. Office COM hates service accounts — don't fight it, just give it a real user identity.