Fixing RPC_S_COMM_FAILURE (0X0000071C) on Windows Server

When This Error Appears

You're managing a Windows Server 2019 or 2022 box, and suddenly an application that talks to a remote server throws RPC_S_COMM_FAILURE (0X0000071C). Maybe it's a backup agent failing to connect to the backup server, or a management tool like Windows Admin Center can't reach a remote machine. The exact error text reads: A communications failure occurred during an RPC. The call didn't even start — it died before the handshake finished.

Root Cause

RPC needs two things to work: the remote machine must be reachable on port 135 (the RPC endpoint mapper), and the RPC service on the remote server must be able to respond on a dynamic high port (typically 49152–65535). What's actually happening here is that the client contacts the server on port 135, asks where the RPC service is listening, and the server replies with a dynamic port. Then the client tries to connect to that port — and fails. The reason it fails is almost always one of these:

• A firewall block on the dynamic port range
• The RPC service (RpcSs) isn't running on the remote server
• DCOM permissions are too restrictive
• A network issue — dropped packets, wrong DNS, or a VPN that doesn't route RPC traffic

Stop chasing the error code blindly. Start with the network.

Fix: Step-by-Step

Step 1: Verify RPC Service Is Running on the Remote Server

1. Remote Desktop or console into the target server.
2. Open Services (services.msc).
3. Check Remote Procedure Call (RPC). It should be Running and set to Automatic.
4. Also check Remote Procedure Call (RPC) Locator — set it to Automatic and start it if it's stopped. Without this, clients can't find the RPC endpoint mapper.

Step 2: Test Basic Connectivity

From the client machine, run:

Test-NetConnection -ComputerName  -Port 135

If this fails, you've got a network or firewall problem at layer 3 or 4. If it succeeds, the endpoint mapper is reachable. Next, test the dynamic range:

Test-NetConnection -ComputerName  -Port 49152

Pick any port in the high range. If it fails, the firewall is blocking RPC dynamic ports.

Step 3: Open the RPC Dynamic Port Range in Windows Firewall

The real fix is to allow RPC traffic through the firewall without restricting it to a single port. On the remote server, run these PowerShell commands as administrator:

New-NetFirewallRule -DisplayName 'RPC Dynamic Ports' -Direction Inbound -Protocol TCP -LocalPort 49152-65535 -Action Allow
New-NetFirewallRule -DisplayName 'RPC Endpoint Mapper' -Direction Inbound -Protocol TCP -LocalPort 135 -Action Allow

If you're in a domain, push this via Group Policy instead. Don't use the GUI wizard — it's slower and you'll miss the range.

Step 4: Check DCOM Permissions

RPC relies on DCOM for object activation. If permissions are locked down, the call fails silently. Open dcomcnfg → Component Services → Computers → right-click My Computer → Properties. Go to COM Security. Under Access Permissions, click Edit Limits. Make sure ANONYMOUS LOGON and Everyone have Remote Access allowed. Same for Launch and Activation Permissions. Apply, reboot the RPC service (net stop RpcSs && net start RpcSs).

Step 5: Verify DNS and Name Resolution

The client must resolve the server's hostname to the correct IP. Run nslookup . If you get the wrong IP or a timeout, fix your DNS. RPC is picky — it uses SPN checks and hostnames, not just IPs. Add a static entry in C:\Windows\System32\drivers\etc\hosts if DNS is flaky.

Step 6: Restart the RPC Service (Last Resort)

If none of the above works, restart both RPC services on the remote server. But don't do this first — it often masks the real issue. Use:

net stop RpcLocator && net start RpcLocator
net stop RpcSs && net start RpcSs

If It Still Fails

You've done the above and the error persists. Now check these three things:

• Event logs on both client and server — look under System for RPC-related errors (Event ID 10, 11, or 42). They'll tell you exactly which call failed and why.
• Third-party firewall — if your corporate firewall or anti-malware suite has its own RPC inspection (like McAfee or Symantec), disable it temporarily. Some of these tools block RPC traffic even when Windows Firewall is wide open.
• Kerberos or NTLM authentication — RPC can fail if the client and server can't authenticate. Check if the service account running the RPC call has a valid SPN or if the machine accounts are trusted. Use setspn -L to list SPNs.

If you're still stuck after that, grab a network trace with Wireshark on the client. Filter for tcp.port==135 and look for the SMB or DCE/RPC bind response. The failure reason is usually in the packet payload — the server might respond with Access Denied or Unknown Interface. That's your real clue.