Fix CO_E_BAD_SERVER_NAME (0X80004014) remote activation error

Quick answer for advanced users

Check DNS resolution for the server name in the DCOM call, verify SPNs exist for the target service account, and ensure the registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\DefaultLaunchPermission includes the calling user.

What's happening when you see 0X80004014

This error shows up when a local app tries to activate a COM object on a remote server, but Windows can't figure out where that server is. I've seen this a ton with SQL Server Reporting Services, Exchange management tools, and even custom .NET apps using Activator.CreateInstance across machines. The error code itself – 0x80004014 – maps to CO_E_BAD_SERVER_NAME, and it's not a network connectivity problem. The target machine is reachable by ping, but the DCOM runtime can't resolve the server name you passed. Usually it's one of three things: DNS can't find the hostname, the SPN (Service Principal Name) is missing or wrong, or the DCOM launch permissions are screwy.

Last month I had a client whose finance app crashed every morning. Turned out their DHCP server handed out a different DNS suffix than the static entry in the DCOM config. Took two hours to find, ten seconds to fix.

Fix steps

Step 1: Confirm DNS resolution

On the machine throwing the error, open Command Prompt and run:

nslookup RemoteServerName

Replace RemoteServerName with the actual name your app uses. If it fails or returns the wrong IP, check your DNS server or hosts file. You can add a static entry in C:\Windows\System32\drivers\etc\hosts as a temporary workaround, but fix DNS properly.

Step 2: Verify the SPN exists

DCOM uses Kerberos for authentication when crossing machine boundaries. If the SPN is missing, it falls back to NTLM, which breaks remote activation. On a Domain Controller, run:

setspn -L Domain\ServiceAccount

Look for an entry like HOST/RemoteServerName or MSOMHSvc/RemoteServerName. If none exist, create one:

setspn -A HOST/RemoteServerName Domain\ServiceAccount

Step 3: Check DCOM launch permissions

Open dcomcnfg (Component Services), expand Component Services > Computers > My Computer, right-click and select Properties. Go to the COM Security tab. Under Launch and Activation Permissions, click Edit Limits. Make sure the user account running the client app has Remote Launch and Remote Activation permissions. If not, add them. This is the one that catches people – they set local permissions but forget remote.

Alternative fixes if the main ones don't work

Disable the loopback check (if both machines are the same server)

Sometimes the error happens when a service on ServerA tries to activate a COM object on ServerA using its FQDN. Windows blocks Kerberos loopback. Fix it by adding this registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck
DWORD value: 1

Then reboot. Use this only for testing – it's a security risk.

Switch from named pipes to TCP/IP for DCOM

If the app uses named pipes by default, you can force TCP/IP. Add this registry key on the client:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole\EnableDCOM
DWORD value: Y

Also set HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\DefaultProtocols to include ncacn_ip_tcp first. Had a QuickBooks POS setup that only worked after this tweak.

Use IP address instead of hostname (dirty but works)

If your app lets you configure the server name, plug in the IP address directly. It bypasses DNS and SPN checks. Not ideal for production because IPs change, but great for troubleshooting. Had a medical imaging app that only activated when I used the IP.

Prevention tip

Always use FQDNs in DCOM configurations, not NetBIOS names. And make sure your DNS is set up with forward and reverse lookup zones. I see this error spike after a server rename or IP change. When you rename a server, run setspn -R OldName and setspn -A HOST/NewName immediately. Also update any DCOM client configs pointing to the old name – they don't auto-resolve.

If you're building distributed apps, test with explicit credentials using CoInitializeSecurity instead of relying on default permissions. Saves hours of debugging later.