Fixing RPC_NT_PIPE_CLOSED (0XC003005F) on Windows Server

You’re seeing RPC_NT_PIPE_CLOSED (0xC003005F) on a Windows Server, probably Server 2016 or 2019. The RPC pipe object closed before the operation finished. This happens most often during cross-domain authentication, file replication, or remote management. I’ve fixed this dozens of times. Here’s what actually works.

1. Firewall blocking RPC dynamic ports

The culprit is almost always a firewall that doesn’t allow RPC dynamic ports. RPC uses port 135 for the endpoint mapper, then negotiates a random high port (typically 49152-65535) for the actual communication. If that random port gets blocked, the pipe closes with 0xC003005F.

How to fix it

1. Open Windows Firewall with Advanced Security on the target server.
2. Check for inbound rules allowing Remote Service Management (RPC). If it’s missing, add it through the Predefined Rules section—don’t create a custom rule here, the built-in one handles RPC dynamic ports correctly.
3. Alternatively, restrict RPC to a fixed port range. Run this on the target server:

netsh advfirewall firewall add rule name="RPC Dynamic Ports" dir=in protocol=TCP localport=135 action=allow
netsh advfirewall firewall add rule name="RPC High Ports" dir=in protocol=TCP localport=49152-65535 action=allow

If you’re on a corporate network with strict rules, set a smaller port range on the server via registry:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet]
"Ports"="50000-51000"
"PortsInternetAvailable"="Y"

Reboot the server after changing the registry. Then open only that port range in your firewall. This locks things down and avoids the all-high-ports mess.

2. Authentication timeout or Kerberos issues

If the firewall’s clean, the next suspect is an authentication timeout. The RPC call starts, waits for a Kerberos ticket, and the pipe sits idle too long. Happens a lot when the domain controller is slow or across slow WAN links.

Check the event logs

Open Event Viewer → Windows Logs → System. Filter for Event ID 5719 (netlogon failure) or 5805 (authentication error). If you see those, your RPC pipe is timing out waiting for domain auth.

The fix: adjust RPC timeout via registry

reg add "HKLM\SOFTWARE\Microsoft\Rpc" /v "RpcTimeout" /t REG_DWORD /d 120000 /f

That sets a 2-minute timeout (120000 ms). Default is 30 seconds—too tight for slow networks. Reboot the server.

Also check Kerberos maximum ticket size

If you’re using nested group memberships (over 10 groups), the ticket can exceed the default buffer. RPC doesn’t like that. On the DC, run:

dsconfig ad -c -d 1 -e "KerberosSizeLimit=65535"

Then reboot both DC and client. I’ve seen this fix a surprising number of 0xC003005F cases.

3. DCOM configuration corruption or permission mismatch

This one’s rarer, but it bites when someone touches DCOM settings incorrectly. The RPC pipe closes because the DCOM service can’t impersonate the caller’s security context.

Diagnose it

Open Component Services (dcomcnfg). Go to Component Services → Computers → My Computer → right-click → Properties. Click the Default Properties tab. Make sure Enable Distributed COM on this computer is checked. Then check the Default Authentication Level — set it to Connect (not None or Packet Integrity unless you know what you’re doing).

Reset default permissions

Still in My Computer Properties, go to COM Security tab. Under Access Permissions, click Edit Default. Add SYSTEM, Administrators, and Interactive with Allow — each should have Local Access and Remote Access. Do the same under Launch and Activation Permissions. Apply and reboot.

If that doesn’t work, check the specific DCOM app under Component Services → DCOM Config. Look for apps that show a gray icon (disabled). Right-click → Properties → Security tab → check all three permission sections. Reset any that say “Use Default” to Custom and explicitly add the same groups mentioned above. I’ve seen third-party backup agents get hosed here.

Quick-reference summary table

Start with the firewall check—that’s 8 out of 10 cases. If you’re on a domain with slow DCs, jump to cause 2. DCOM is the last resort. Reboot after each change or the pipe might stay busted until the next service restart.