CO_E_WRONG_SERVER_IDENTITY (0X80004015) Fix: Run as Security ID Mismatch

Cause #1: The DCOM Application Is Configured to Run Under a Specific User Account That No Longer Exists or Has Changed

This is the one I see most often. You're running some legacy app—a barcode scanner driver, a cash register interface, an old ERP client—and it throws CO_E_WRONG_SERVER_IDENTITY (0X80004015). The root cause is almost always in Component Services (dcomcnfg). Some DCOM class was set up to run under a specific user account (maybe a domain admin from 2012) and that account got disabled, renamed, or the domain changed. The caller's security context doesn't match the configured identity, so Windows slams the door.

How to fix it

1. Open Component Services (run dcomcnfg as admin).
2. Navigate to Component Services > Computers > My Computer > DCOM Config.
3. Find the specific application throwing the error. It's usually named after the software (e.g., "EPSON OPOS Service" or "AcmePOS Server").
4. Right-click it, go to Properties > Identity tab.
5. If it's set to "This user", check if that account still exists and is enabled. If not, switch to "The launching user" or "The interactive user" depending on what the vendor recommends. For most line-of-business apps, "The launching user" works fine.
6. Click OK, then test the app.

Cause #2: Group Policy or ADMX Templates Overriding the DCOM Identity

Had a client last month whose entire print queue died because of this. They moved to a new domain controller and suddenly every COM+ app on the server threw 0X80004015. Turns out a new Group Policy applied a restrictive DCOM launch permission template that forced all out-of-process COM servers to run under NT AUTHORITY\LOCAL SERVICE. The software expected NT AUTHORITY\SYSTEM—identity mismatch, error.

How to fix it

1. Run rsop.msc on the affected machine as admin to see what policies apply to DCOM.
2. Look under Computer Configuration > Administrative Templates > Windows Components > Application Compatibility for any DCOM-related policies.
3. Also check Computer Configuration > Windows Settings > Security Settings > Local Policies > Security Options for DCOM: Machine Launch Restrictions in Security Descriptor Language.
4. If a policy is overriding the identity, either remove the affected machine from that policy's scope or create a WMI filter that excludes it.
5. After changing policy, run gpupdate /force and reboot.

Cause #3: Corrupted Registry Entry for the CLSID or AppID

This one's less common but when it hits, it's a bear. The registry has a CLSID (class ID) pointing to an AppID, and the AppID's RunAs value references a user SID that doesn't exist on the machine. This can happen after a botched uninstall or a registry cleaner that mangled the COM entries.

How to fix it

1. Open Registry Editor as admin.
2. Navigate to HKEY_CLASSES_ROOT\CLSID\{your-clsid}. Find the CLSID from the error—you can get it from Event Viewer under Windows Logs > System with source DCOM.
3. Check the AppID value there—it's a GUID like {1234...}.
4. Now go to HKEY_CLASSES_ROOT\AppID\{that-guid} and look for RunAs value (REG_SZ). If it says a username like DOMAIN\OldUser, that's your problem. Delete the RunAs value or change it to a valid account.
5. If the user doesn't exist, remove RunAs entirely—Windows will default to the launching user for interactive apps.
6. Restart the COM+ service: net stop COMSysApp && net start COMSysApp.

Pro tip: Always export the registry key before making changes. One wrong delete and you're re-registering the whole COM class. Saved my skin more than once.

Quick-Reference Summary Table

If none of these nail it, you're likely dealing with a COM+ catalog corruption or a malicious third-party software that hijacked the COM registration. Run sfc /scannow and DISM /Online /Cleanup-Image /RestoreHealth, then re-register all COM+ components with regsvr32 on the affected DLLs. That's deeper than 99% of cases need to go, but it's the nuclear option.