Fix CO_E_LAUNCH_PERMSSION_DENIED (0X8000401B) error on Windows

You're working with an app — maybe a custom .NET service, a SQL Server linked server, or a third-party tool that talks to another Windows component — and boom, you get this error: CO_E_LAUNCH_PERMSSION_DENIED (0X8000401B). The message says "The client is not allowed to launch this server." This shows up in event logs, in app trace files, or as a popup in MMC. I've seen it most often when a service runs under a low-privilege account and tries to start a COM+ or DCOM component. Or when you move an app from a dev machine to a locked-down server. It's infuriating because the app feels broken but Windows itself isn't crashing.

What's going on?

COM (Component Object Model) and DCOM let programs talk to each other across processes or even machines. When your app tries to "launch" a COM server — for example, to create an instance of a specific object — Windows checks the DCOM launch permissions. If the user account running the client app doesn't have the right to launch that server, you get error 0X8000401B. The trigger is almost always a permission mismatch. The "server" here isn't a physical computer; it's a COM component registered in the system, often with a GUID.

Where to fix it

You fix this in Component Services (dcomcnfg). It's a Microsoft Management Console snap-in. Do not use Registry Editor directly unless you enjoy pain — Component Services handles the permission inheritance correctly.

1. Press Win + R, type dcomcnfg, hit Enter. This opens Component Services.
2. In the left pane, expand Component Services → Computers → right-click My Computer → choose Properties.
3. Go to the COM Security tab. This is where the magic lives.
4. Under Launch and Activation Permissions, click Edit Limits. Don't touch the other button unless you know what you're doing.
5. In the dialog, you'll see a list of users and groups with permissions. By default, Administrators, SYSTEM, INTERACTIVE, and sometimes Everyone are listed. If your app runs under a service account (like NT AUTHORITY\NETWORK SERVICE or a domain account), that account must have at least Local Launch and Local Activation checked under Allow.
6. Click Add, type the account name (e.g., NT AUTHORITY\NETWORK SERVICE), check Allow for both Local Launch and Local Activation. Click OK.
7. Click Apply and OK on all windows.
8. Restart your application or the service that was failing. Sometimes a full reboot clears the cached COM permissions — I've seen it hang on Server 2016 after permission changes.

But it still fails — what do I check next?

If the fix above doesn't work, here are the next things to look at:

• Check the specific COM server's launch permissions. Some COM components have their own security settings that override the machine-wide ones. In dcomcnfg, expand Component Services → Computers → My Computer → DCOM Config, find the GUID or name of the server (the error log often tells you the CLSID), right-click → Properties → Security tab. Set launch permissions there too.
• Look at the app's identity. Is the app running as a user that belongs to the local Administrators group? Sometimes that's the only way, but don't do it unless you have to. Better to use a dedicated service account with the right permissions.
• Check Windows Firewall. For remote DCOM (machine to machine), you need RPC ports open. But for local launch, firewall usually isn't the problem. Still, if it's a network path, verify.
• Use Process Monitor. Run Procmon from Sysinternals, filter by the failing process name, and look for ACCESS DENIED on registry keys. The COM launch permission is stored under HKCR\CLSID\{GUID} and HKLM\SOFTWARE\Microsoft\Ole. But honestly, the dcomcnfg GUI is easier.

Shortcut if you're on a domain: If the server is running on a domain-joined machine and the client account is from the same domain, sometimes adding Domain Users with Launch and Activation permissions to the machine-wide limits works. But be cautious — that opens the door for any domain user to launch COM components. Use sparingly.

That's it. This error is almost always a permission problem, and once you know where to look, it's a 5-minute fix. I've fixed this on Windows 10, Server 2012 R2, Server 2016, and Server 2019 — same steps every time. Good luck.