Fix 0x8000401D CO_E_REMOTE_COMMUNICATION_FAILURE

You're running a distributed COM application — maybe a management console, a custom in-house tool, or something from an ISV — and it bombs out with CO_E_REMOTE_COMMUNICATION_FAILURE (0x8000401D). The exact trigger is almost always an attempted DCOM (Distributed COM) call from your machine to a remote server, and Windows flatly refuses to make the connection. This shows up most often after a Windows Update reboot or a firewall policy change, because both can silently kill the RPC endpoints DCOM relies on.

What's actually happening here

DCOM is built on top of RPC (Remote Procedure Call). For DCOM to work, the client machine needs to (1) resolve the server's name or IP, (2) connect via TCP port 135 (the RPC Endpoint Mapper), and (3) negotiate dynamic port assignments for the actual COM communication. The 0x8000401D error means step 2 or 3 failed. The reason step 3 works is that DCOM dynamically allocates ports in the range 49152–65535 (Windows Vista and later) — but the firewall on either side has to allow those ports through. If the firewall or the RPC configuration blocks them, you get this error.

The fix — three things to check in order

Don't jump ahead. Do them in this sequence — each builds on the last.

Verify basic network connectivity
From your client machine, open a command prompt and run:
```
ping <server-hostname>
```
If ping fails, you have a basic DNS or routing problem. Fix that first. Also check:
```
nslookup <server-hostname>
```
Make sure the returned IP is correct. An old DNS cache can point to a dead server.
Check the RPC Endpoint Mapper port (TCP 135)
From the client, test TCP port 135 on the server:
```
Test-NetConnection -ComputerName <server-hostname> -Port 135
```
Or on older systems use telnet <server-hostname> 135. If port 135 is blocked, DCOM can't even start. The usual culprit is Windows Firewall or a third-party firewall on the server. On the server, open wf.msc, go to Inbound Rules, and make sure Remote Service Management (RPC-EPMAP) is enabled for the relevant profile (Domain, Private, or Public). If you disabled it, enable it.
Open the DCOM dynamic port range
Even with port 135 open, the actual COM traffic uses high ports. On the server, create a firewall rule that allows inbound TCP ports 49152–65535. In wf.msc, create a new Inbound Rule, choose Port, then TCP, then Specific local ports: 49152-65535. Name it something obvious like DCOM Dynamic Ports. If your environment restricts port ranges, you can narrow it — but start with the full range for testing.

If it still fails

Here are the less common gremlins:

DCOM launch and access permissions
Open dcomcnfg → Component Services → Computers → right-click My Computer → Properties → COM Security tab. Under Launch and Activation Permissions, click Edit Limits. Make sure the user account running the client application has Local Launch and Remote Launch permissions. If the server is in a domain, also check the Access Permissions section — the Remote Access permission needs to be granted.
Authentication level mismatch
In the same My Computer Properties dialog, check the Default Properties tab. The Default Authentication Level should be at least Connect. If it's set to None, DCOM calls won't authenticate and can fail silently with this error.
Windows Defender Firewall with Advanced Security logging
Enable logging to see exactly which packets are dropped. In wf.msc, right-click Windows Defender Firewall with Advanced Security → Properties → Domain Profile tab (or whichever profile is active) → Customize next to Logging. Set Log dropped packets to Yes. Then reproduce the error and check %SystemRoot%\System32\LogFiles\Firewall\pfirewall.log for blocked connections from the client IP to the server IP.
Group Policy overriding firewall settings
If you're in a corporate domain, GPOs can lock down firewall rules. Run gpresult /r on the server to see which policies apply. If a GPO blocks RPC or DCOM ports, you need to get an exception from your network admin — no local rule will override it.

One last thing: if you recently patched Windows, check the installed updates. Some cumulative updates have been known to change DCOM security defaults. The October 2021 updates, for instance, hardened DCOM by default and broke a lot of legacy apps. If nothing else works, try uninstalling the most recent update (temporarily) to confirm it's the cause — then you'll know to target the specific registry key or GPO setting that the update changed.