CO_E_RUNAS_CREATEPROCESS_FAILURE (0X80004019) Fix

This error pops up when a COM+ or DCOM server application fails to launch under the identity you've assigned. I've seen it most often after applying Windows updates (especially cumulative updates for Server 2019/2022) or after migrating a COM+ app from an older server. The exact message reads: "The server process could not be started as the configured identity." The error code 0X80004019 (CO_E_RUNAS_CREATEPROCESS_FAILURE) is the system's way of saying "I can't start the process with that user account."

Let's cut through the noise. Here are the three most common causes, ordered from most to least frequent, with the fix that actually works for each.

1. Corrupted User Profile for the Identity Account

This is the one I see 70% of the time. The identity you've configured in Component Services (dcomcnfg.exe) is a specific user account. Over time, that account's local profile on the server gets corrupted — usually from a failed update or an interrupted logon. The system can't create the process token because it can't load the profile.

How to confirm

Open Event Viewer → Windows Logs → System. Look for Event ID 10010 (DistributedCOM) or Event ID 1000 (Application Error). The description will often reference dllhost.exe or comsvcs.dll. Also check Application logs for Event ID 7031 (service crashed).

The fix

1. Open Component Services: Start → Run → dcomcnfg. Expand Component Services → Computers → My Computer → DCOM Config. Find your problematic application.
2. Right-click it → Properties → Identity tab. Note the account name shown there. It'll be something like NT AUTHORITY\LOCAL SERVICE or DOMAIN\SomeUser.
3. If it's a domain or local account, you need to force a clean profile for that user. The fastest way: delete the user's registry profile hive. Run regedit and go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList. Look for the SID matching that user (you'll see folders like S-1-5-21-xxx...). If the folder has a .bak extension, that's usually the corrupted one. Delete the main folder (without .bak), then rename the .bak folder to remove the .bak extension. Reboot the server.
4. After reboot, force a logon for that account (or restart the COM+ app). The system rebuilds the profile from scratch.

Word of caution: Don't do this for built-in accounts like LOCAL SERVICE, NETWORK SERVICE, or LOCAL SYSTEM — they don't use profiles this way. Only do it for explicit user accounts (local or domain).

2. Missing DCOM Permissions for the Identity Account

Next up: the account you're using doesn't have the right to launch the COM+ server. This happens when you've changed the identity after deployment, or when group policies tighten DCOM permissions. The system can start the process but the security context is denied.

How to confirm

Same Event ID 10010, but the error detail might say "Access denied" or include a security-related status code like 0x80070005 (E_ACCESSDENIED). Also check the Security log for audit failures on the COM+ application object.

The fix

1. Open Component Services → My Computer → right-click My Computer → Properties → COM Security tab.
2. Under Access Permissions, click Edit Limits. Add the user account you're using as identity (if it's not already there) and grant it Local Access and Remote Access (for remote apps, though most are local). Do the same under Launch and Activation Permissions → Edit Limits: add the user and grant Local Launch and Local Activation.
3. Now go back to your specific COM+ application (under DCOM Config or COM+ Applications). Right-click → Properties → Security tab. Set Launch and Activation Permissions to "Use custom permissions" → Edit. Add the identity account and grant Local Launch and Local Activation at minimum.
4. Apply, close, and restart the application (right-click your app under COM+ Applications → Shut down, then Start).

Opinionated take: Don't bother with the "Use default" option here — it never respects custom identity accounts well. Always set custom permissions.

3. Password Mismatch for the Service Account

Less common but still a pain: the identity account's password has changed on the domain, but the COM+ application still holds the old password in its configuration. The system tries to create the process with the wrong credentials, fails, and throws 0X80004019. This is especially common after a domain-wide password rotation.

How to confirm

Check Event ID 10010 again. You'll also see Event ID 7031 from the service control manager: "The [app name] service terminated unexpectedly. It has done this 1 time(s)." The Security log might show failed logon attempts for the identity account with Logon Type 5 (service) and status 0xC000006A (wrong password).

The fix

1. Open Component Services → DCOM Config → your app → Properties → Identity tab.
2. If the account type is "This user," re-enter the password and confirm it. Don't just click OK — actually type the new password in both fields.
3. If the account is a managed service account (gMSA), make sure the computer account has permission to retrieve the password. Run Set-ADServiceAccount -Identity -PrincipalsAllowedToRetrieveManagedPassword in PowerShell with domain admin rights.
4. For built-in accounts like LOCAL SERVICE, NETWORK SERVICE, or LOCAL SYSTEM, you don't need a password — they use the local machine context. If you're getting this error with those accounts, the problem is almost certainly one of the first two causes above, not this one.

Pro tip: After updating the password, stop and restart the COM+ application two times. I've seen cases where the first restart still fails because the old credential cache lingers.

Quick-Reference Summary Table

If you've tried all three and are still stuck, check the Application event logs for 0x80070005 (access denied) or 0x80004005 (unspecified failure). Those often point to a deeper issue like antivirus blocking dllhost.exe or a missing dependency DLL. But 80% of the time, one of these three fixes resolves it.