Fix RPC_NT_COMM_FAILURE 0XC0020052 in Windows Server

When This Error Shows Up

You're trying to connect remotely to a Windows Server — maybe through MMC for Event Viewer, or running a WMI query from PowerShell, or using a management tool like SCCM. Halfway through you get hit with RPC_NT_COMM_FAILURE (0XC0020052) and the connection drops dead.

I see this most often when someone tries to open Computer Management on a remote server across a subnet, or when a DCOM-based app (like a backup agent) tries to register with a central server. The remote machine is reachable via ping, but the RPC call just won't complete.

Root Cause — What's Really Happening

RPC needs two-way communication. Your client sends a request to the remote server's port 135 (the Endpoint Mapper). The server then responds with a dynamic high port — typically between 49152 and 65535 on modern Windows — where the actual service is listening. If that high port is blocked by a firewall, or if DNS can't resolve the server's name back to its own IP, the client gets 0XC0020052.

Three things cause this 90% of the time:

1. A firewall (Windows Firewall or a hardware firewall) blocking the RPC dynamic ports.
2. DNS resolution failure — the remote server doesn't know its own name, or the client can't resolve the server's IP to a name.
3. RPC services not running — Remote Procedure Call (RPC), RPC Endpoint Mapper, or DCOM Server Process Launcher are stopped.

Don't waste time chasing domain permissions or network hardware until you've checked these three. I've seen admins swap switches and rejoin domains when the real fix was a disabled firewall rule.

The Fix — Step by Step

Step 1: Verify RPC Services Are Running

On the remote server, open Services.msc (or run services.msc as admin). Look for these three services:

• Remote Procedure Call (RPC) — should be Running, startup type Automatic.
• RPC Endpoint Mapper — Running, Automatic.
• DCOM Server Process Launcher — Running, Automatic.

If any are stopped, right-click and Start, then set startup type to Automatic. After you do that, try your RPC call again. If it works, you're done. If not, move on.

Step 2: Check Windows Firewall Rules for RPC

Open Windows Defender Firewall with Advanced Security on the remote server. Go to Inbound Rules. Look for rules named something like Remote Service Management (RPC) or Remote Event Log Management (RPC).

Here's the trick: there's usually a group of rules. You need the ones that allow RPC dynamic port traffic. Enable them if they're disabled. But be careful — some of these rules are scoped to the local subnet only. If your client is on a different subnet, you need to edit the rule and change the scope to allow any IP, or add your client's subnet explicitly.

To do that: right-click the rule, go to Properties > Scope tab, and under Remote IP address, add your client's IP range. Apply and OK.

Step 3: Open Up the RPC Dynamic Port Range

If the built-in rules aren't cutting it (or you're behind a corporate firewall), you can restrict RPC to a fixed range of ports. That makes firewall rules cleaner. On the remote server:

1. Open Registry Editor (regedit) as admin.
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet.
3. If the Internet key doesn't exist, create it (right-click Rpc > New > Key, name it Internet).
4. Inside that key, create two DWORD (32-bit) values:
   • Ports — set value to 50000-51000 (or any range you pick).
   • PortsInternetAvailable — set value to 1.
5. Reboot the server (or restart the RPC service, but a reboot is safer).

Then on your firewall (Windows Firewall or hardware), allow inbound traffic to TCP ports 50000-51000 plus TCP port 135. That's it.

Step 4: Fix DNS Resolution

This one bites people hard. From the remote server, run ipconfig /all. Check the hostname and the primary DNS suffix. Then run ping -a <server's own IP>. It should return the server's FQDN. If it doesn't, or if it returns a different name, DNS is broken.

Quick fix: add the server's own IP and hostname to the hosts file at C:\Windows\System32\drivers\etc\hosts. Add a line like:

192.168.1.100  server01.domain.com  server01

Replace the IP and hostnames with the actual ones. Then flush DNS with ipconfig /flushdns and test again.

What to Check If It Still Fails

If you've done all four steps and still get 0XC0020052, here's the deeper stuff:

• Check the remote server's default gateway. If it's wrong, RPC packets can't route back to your client. Run route print and verify the gateway.
• Try disabling Windows Firewall temporarily (on the remote server only, in a test environment). If it works with the firewall off, you missed a rule — go back to Step 2 and be more thorough.
• Look for third-party antivirus firewalls. McAfee, Symantec, and others often block RPC traffic even when Windows Firewall is off. Check those separately.
• Run a packet capture with Wireshark or NetMon on the remote server. Filter for TCP traffic to port 135 and the dynamic range. You'll see if the server is sending a response that's being blocked or dropped.
• Check the Application and System event logs on the remote server for RPC-related errors. Look for Event ID 10010 (DCOM) or 7031 (service crash).

That covers it. Nine times out of ten, it's either the firewall rules or DNS. Start there, and you'll spend more time fixing it than diagnosing it.