CO_E_START_SERVICE_FAILURE (0x8000401C) — Service Won't Start

Quick answer: Open Component Services, find the failing COM class, and grant Launch and Activation permissions to the service's logon account (usually LOCAL SYSTEM or NETWORK SERVICE).

You're seeing 0x8000401C because a COM server — typically one that runs as a Windows service — can't start. What's actually happening here is the COM runtime (RPCSS) is trying to launch the server on behalf of some client, but the service's security descriptor or logon account doesn't have the right to start it. This isn't a missing file; it's a permission mismatch. The most common trigger? Someone migrated an app from an older Windows version, or you're running a third-party service that expects to impersonate a specific user but can't.

Why This Happens

The COM infrastructure in Windows uses a service called RPCSS (Remote Procedure Call Subsystem) to broker communication between client apps and COM servers. When a client calls CoCreateInstance, RPCSS checks the COM class's Launch and Activation Permissions. If the service account running the server doesn't have these permissions, RPCSS refuses to start it and returns 0x8000401C. The event log usually shows Event ID 10010 — "The server did not register with DCOM within the required timeout."

Fix Steps

1. Identify the failing COM class — Open Event Viewer (eventvwr.msc), go to Windows Logs → System. Look for Event ID 10010. The description will include the CLSID (a GUID like {12345678-1234-1234-1234-123456789012}). Write down that GUID.
2. Open Component Services — Run dcomcnfg. Navigate to Component Services → Computers → My Computer → DCOM Config. Find the entry whose CLSID matches the one from the event log. If you don't see it, the class is probably a service — right-click any entry, choose Properties, look at the AppID value to cross-reference.
3. Check the service's logon account — Open services.msc. Find the service that hosts the COM class (the description in the event log often says the service name). Right-click → Properties → Log On tab. Note the account — it's usually NT AUTHORITY\LOCAL SERVICE, NETWORK SERVICE, or LOCAL SYSTEM.
4. Grant Launch and Activation permissions — Back in DCOM Config, right-click the COM class → Properties → Security tab. Under "Launch and Activation Permissions", select "Customize" then click Edit. Add the service account you found in step 3. Grant it Local Launch, Remote Launch, Local Activation, and Remote Activation. Click OK.
5. Restart the service — Go back to services.msc, right-click the service → Restart. Then try the operation that was failing.

Alternative Fixes

If the main fix didn't work, the problem might be deeper:

• Corrupted COM registration — Unregister and re-register the DLL or EXE that implements the COM class. For a DLL, run regsvr32 /u path\to\dll then regsvr32 path\to\dll as Administrator. For an EXE, run it with the /regserver flag (e.g., MyService.exe /regserver).
• DCOM identity mismatch — In the DCOM class Properties → Identity tab, change the user to "The interactive user" or specify the same account the service runs under. Some classes expect to run as a specific user, not as the launching user.
• Antivirus interference — Some security tools block COM launches for certain processes. Temporarily disable the antivirus to test. If that fixes it, add an exclusion for the service executable.

Prevention Tip

When deploying a COM server as a Windows service, always set its Launch and Activation permissions in the DCOM config before you distribute it. Use OleView .NET or dcomperm (a command-line tool from the Windows SDK) to script these permissions. The reason step 3 works is that RPCSS compares the service's token against the DCOM security descriptor at launch time — if the token isn't listed, you get the error. Pre-loading the right accounts avoids the scramble.