Fix CO_E_CREATEPROCESS_FAILURE (0X80004018) in COM+

Quick answer: Open Component Services, find the failing COM+ application, right-click Properties, go to Identity tab, and set Interactive user (or a specific admin account). Then restart the service.

Why you're seeing 0x80004018

I know this error is infuriating — it usually pops up when you're trying to connect to a COM+ component from a client machine or a web app, and suddenly everything goes dark. The error code 0x80004018 maps to CO_E_CREATEPROCESS_FAILURE, which literally means the server process (usually dllhost.exe) couldn't start. In my six years running a help desk blog, I've seen this most often on Windows Server 2012 R2 and 2016, but it hits Windows 10 too.

The real trigger is almost always one of three things:

1. The COM+ application's identity is set to an account that's lost permissions or been disabled.
2. A COM+ component's DLL is corrupt or missing a dependency.
3. The COM+ system service (COMSysApp) isn't running.

Let's fix it.

Step 1: Verify the COM+ System Application service

Open Services.msc (Win+R, type services.msc). Find COM+ System Application. If it's not running, right-click and Start it. Set it to Automatic if it's not already. This tripped me up the first time too — it's easy to miss.

Step 2: Check the failing COM+ application's identity

Open Component Services (Win+R, type dcomcnfg). Expand Component Services > Computers > My Computer > COM+ Applications. Find the specific app throwing the error — it might be highlighted in yellow or show a status like "Stopped". Right-click it, go to Properties > Identity.

Most third-party apps default to Interactive user. If someone changed this to a specific account, that account might be locked out or its password expired. Switch to Interactive user for testing. If that fixes it, you'll need to set it to a dedicated service account with proper permissions — but first confirm the account can actually log on locally (check Local Security Policy > User Rights Assignment > Log on as a batch job).

Step 3: Check the DLL's dependencies

If the identity is fine, the DLL hosting the COM+ component could be busted. Use Dependency Walker (or dumpbin /dependents from a Developer Command Prompt) to inspect the DLL. Common culprits are missing VC++ redistributables or a corrupt .NET Framework installation. Reinstall the relevant runtime — for example, if the DLL is a .NET assembly, run ngen update from an admin prompt.

Step 4: Re-register the COM+ application

Right-click the COM+ application in Component Services and choose Shut down. Then delete it (Back up any config first!). Re-create it by importing the original .MSI or .COM file. I've seen this clear up weird corruption that reboots don't fix.

Alternative fixes if the main steps don't work

• Check the Windows event log: Open Event Viewer > Windows Logs > Application. Look for errors source "COM" or "COM+' — they'll often name the exact DLL and account.
• Run a system file check: Open an admin CMD and run sfc /scannow. This has saved me on Server 2012 when COM+ system files got corrupted by a bad update.
• Disable anti-virus temporarily: Some security software blocks dllhost.exe from spawning. Test by disabling real-time protection for 5 minutes.
• Reset COM+ security permissions: In Component Services, right-click My Computer > Properties > COM Security. Under Access Permissions and Launch and Activation Permissions, ensure Everyone and NETWORK SERVICE have at least Remote Launch and Local Activation. This is overkill, but I've had to do it on locked-down servers.

How to prevent this from coming back

Once you've fixed it, document the service account password expiry. If it's set to a domain account, make sure the password never expires or set up a scheduled task to update the COM+ application identity. Also, keep your COM+ components' dependencies updated — missing VC++ runtimes are a sneaky cause.

One more thing: if you're running this on a terminal server or RDS host, the Interactive user identity will fail for remote sessions. You'll need to set it to This user with a dedicated account that has Log on as a batch job rights.

That's it. Go kill that 0x80004018.