RPC_NT_PIPE_EMPTY (0XC0030061) — Why It Happens and How to Fix

You're hitting RPC_NT_PIPE_EMPTY (0XC0030061) — the exact text is "No more data is available from the RPC pipe". I see this most often in two scenarios: when a Windows Server 2022 or 2019 machine tries to communicate with a legacy app over DCOM (like a SQL Server linked server query or an Exchange Management Console remote call), and when an RPC client times out after the server already closed the named pipe. The trigger is almost always a server-side issue, not the client.

Root Cause

What's actually happening here is the RPC runtime (Rpcrt4.dll) opens a named pipe between client and server — usually \pipe\epmapper or an endpoint-specific pipe. The client sends a request, but the server terminates the connection before sending the full response. The RPC runtime on the client then throws 0xC0030061 because it can't read any more bytes from the pipe.

The reason the pipe empties isn't random. The server usually closes it because:

• The RPC server process crashed or hit an unhandled exception — most common with old COM+ components or custom services.
• A firewall or network device killed the TCP connection mid-stream, and the named pipe endpoint got orphaned.
• Memory or handle exhaustion on the server — the RPC server runs out of thread pool threads or waits for a lock that's held too long.
• Authentication mismatch — the server rejects the client after the pipe is established (this one's rare but sneaky).

Skip the "restart the RPC service" advice — that's cargo cult. The real fix depends on which server-side component is dropping the pipe.

Fix — Step by Step

1. Identify the RPC server process. Run this on the server where the error originates:

netstat -ano | findstr :135
rpcdump /s localhost

Look for the PID listening on port 135 (the RPC endpoint mapper). Then check Task Manager or tasklist /fi "PID eq [PID]" to see what process owns it. Usually svchost.exe hosting the RPC Endpoint Mapper service.

2. Enable RPC tracing. Don't guess — log it. On the server, run as admin:

netsh rpc filter add rule layer=all action=run
netsh rpc start tracing

Then reproduce the client call. Check %windir%\tracing\rpcrt4.etl with tracerpt or the Windows Performance Analyzer. Look for entries with status: 0xC0030061 — they'll show the server endpoint UUID that failed.

3. Check the specific COM/DCOM component. Once you have the UUID, query it:

dcomcnfg

Navigate to Component Services → Computers → My Computer → DCOM Config. Find the component with that AppID. If it's a custom service, verify its identity (the "This user" account) — wrong credentials cause silent pipe drops.

4. Increase the RPC endpoint timeout. If the issue is time-related (the server is slow to respond), tweak the registry on the client:

HKLM\Software\Microsoft\Rpc\ClientProtocols
DefaultTimeout REG_DWORD = 300000 (5 minutes, in milliseconds)

Also check the server's HKLM\Software\Microsoft\Rpc\ServerProtocols\EnableRemoteException — set it to 1 to get better error messages instead of generic pipe empties.

5. Restart the RPC server's host process — but only if you've identified it. For example, if it's a third-party Windows service running as an RPC server:

net stop "YourServiceName" && net start "YourServiceName"

This clears stale handles and memory leaks without a full reboot.

Still Failing? Check These

• Named pipe quota. Run fsutil quota query C: — the RPC pipe uses kernel memory. If disk quotas are enabled on the system drive, the RPC server can't allocate pipe buffers.
• WinSock catalog corruption. On the client, run netsh winsock reset and reboot. Corrupted LSPs can break named pipe overlapped I/O.
• IPv6 vs IPv4 mismatch. If the server is multi-homed and the client connects via IPv6 but the server drops to IPv4, the pipe can empty. Disable IPv6 on one side as a test: netsh int ipv6 set state disabled on the client.
• Antivirus filtering RPC traffic. Temporarily disable the AV's network protection (not the whole AV) — some vendors inject into the RPC runtime and kill pipes prematurely.

If none of this works, the fix is architectural: move the communication off raw RPC to a more resilient transport like named pipes directly or WCF with net.tcp binding. Old DCOM apps are notorious for this failure pattern, and no registry tweak can fix fundamentally broken timeout handling in the server code.