DCOM error 0x80010123 – CO_E_FAILEDTOIMPERSONATE fix

The 30-second fix: Check the DCOM app’s startup type

Most times, this error pops up because the DCOM app is set to “Interactive User” and no one is logged in. Had a client last month whose print management tool crashed every night because of this.

1. Press Win + R, type dcomcnfg, hit Enter.
2. Go to Component Services > Computers > My Computer > DCOM Config.
3. Find your app (the one throwing the error). Right-click it, choose Properties.
4. Go to the Identity tab.
   If it’s set to “The interactive user,” change it to “This user” and enter a service account with the right permissions. Or better: pick “The launching user” if the caller has enough rights.
5. Click OK, restart the app or the service.

That fixes it about 40% of the time. If not, move on.

The 5-minute moderate fix: Fix impersonation level and permissions

If the startup type didn’t cut it, we need to check two things: the impersonation level in the app’s code, and the DCOM security settings. I’ve seen this happen with custom .NET COM+ apps that didn’t set impersonation to RPC_C_IMP_LEVEL_IMPERSONATE.

Check the app’s impersonation level

If you wrote the app or can edit its source, make sure it calls CoSetProxyBlanket with an impersonation level of at least RPC_C_IMP_LEVEL_IMPERSONATE. Here’s a C++ snippet:

HRESULT hr = CoSetProxyBlanket(
    pInterface,           // Your proxy
    RPC_C_AUTHN_WINNT,
    RPC_C_AUTHZ_NONE,
    NULL,
    RPC_C_AUTHN_LEVEL_CALL,
    RPC_C_IMP_LEVEL_IMPERSONATE,  // Need this or higher
    NULL,
    EOAC_NONE
);

For .NET, set TokenImpersonationLevel to Impersonation in your WCF or remoting config. If you can’t change the code, skip to the permissions fix.

Fix DCOM launch and activation permissions

1. In the same DCOM Config properties, go to the Security tab.
2. Under Launch and Activation Permissions, click Edit.
3. Add the user or group that’s calling the DCOM app. Give them Local Launch and Local Activation at minimum. If it’s across machines, also check Remote Launch and Remote Activation.
4. Under Access Permissions, do the same: add the caller with Local Access.
5. Click OK all the way out, restart the app.

This solves another 30% of cases. If you’re still stuck, go advanced.

The 15+ minute advanced fix: Drill into the system event log and check the service account

When the first two fail, it’s usually a deeper issue – the service account doesn’t have the “Impersonate a client after authentication” privilege, or there’s a group policy blocking it. I had a client whose domain admins locked this down without telling anyone.

Grant the “Impersonate a client after authentication” privilege

1. Open Local Security Policy (or Group Policy Management Console if domain).
2. Go to Security Settings > Local Policies > User Rights Assignment.
3. Find “Impersonate a client after authentication”.
4. Add the account that runs the DCOM app (e.g., NT AUTHORITY\NETWORK SERVICE or your specific service account).
5. Run gpupdate /force from an admin command prompt, then restart the app.

Check the system event log for more clues

Don’t just guess. Open Event Viewer > Windows Logs > System. Filter by source DCOM or DistributedCOM. Look for Event ID 10016 or 10010. The details will tell you exactly which CLSID and account failed. Write down the CLSID.

Example: The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} to the user NT AUTHORITY\NETWORK SERVICE.

Take that CLSID, go back to DCOM Config, and find the app (you can search by CLSID in the registry at HKEY_CLASSES_ROOT\CLSID\{CLSID}). Then fix its permissions as in the 5-minute fix, but now you know the exact CLSID and account.

Verify the service account’s network access

If the DCOM call is remote, the account needs the “Access this computer from the network” right on the target machine. Check that in the same Local Security Policy > User Rights Assignment. If the account is in the Deny list, remove it.

That’s it. These steps cover 99% of 0x80010123 cases. Start with the quick identity fix, then permissions, then the deep dive. You’ll be up and running in no time.