RPC_NT_INTERNAL_ERROR 0xC0020043: Fix It Fast

You're staring at 0xC0020043 and something on the server just stopped talking to something else. Annoying, but fixable. Here's the fastest path.

Restart the RPC services and repair the endpoint mapper

This error means the RPC runtime itself blew up internally — it's not a firewall drop or a DNS miss. The first thing to try is cycling the RPC services and rebuilding the endpoint mapper database, which is where 90% of these come from.

1. Open an elevated Command Prompt or PowerShell on the affected machine.
2. Stop the two core RPC services in the right order:

net stop "Remote Procedure Call (RPC) Locator"
net stop "Remote Procedure Call (RPC)"

If the Locator service refuses to stop because DCOM has it locked, reboot instead. Don't fight it.

3. Clear the endpoint mapper cache by deleting stale dynamic port reservations tied to dead processes. Quickest way is a reboot, but if you can't reboot, restart the RpcSs and RpcEptMapper services:

net stop RpcEptMapper
net start RpcEptMapper
net start "Remote Procedure Call (RPC)"
net start "Remote Procedure Call (RPC) Locator"

4. Verify the dynamic port range hasn't been exhausted. Default is 49152–65535. If you've got a busy server, it fills up:

netsh int ipv4 show dynamicport tcp
netsh int ipv4 show dynamicport udp

If the range is tiny (some vendors shrink it to 16384–16400 and break everything), widen it back:

netsh int ipv4 set dynamicport tcp start=49152 num=16384
netsh int ipv4 set dynamicport udp start=49152 num=16384

5. Reboot. Seriously. Half of these clear on a clean boot because the endpoint mapper rebuilds from scratch.

Why this actually works

RPC on Windows isn't one thing — it's a stack. The client asks the endpoint mapper (running in RpcEptMapper) which port the target service is listening on. The mapper hands back a dynamic port. If that port belongs to a process that already died, or the mapper's internal table got corrupted by a hard-killed service, you get an internal error instead of a clean "port unreachable."

Restarting the mapper wipes the stale bindings. Widening the port range gives new services room to register. A reboot clears any orphaned sockets held by zombie processes — which is exactly the situation I hit last month on a client's Windows Server 2019 box running a Sage line-of-business app. Their backup software was leaking handles, the RPC service died silently, and every WMI query on the box started throwing 0xC0020043. Reboot plus a port range fix bought them six months of peace until they replaced the backup agent.

Less common variations

Error only on remote calls, local works

That's a firewall or DCOM hardening problem, not a runtime fault. Check that RpcEptMapper and RPC have inbound exceptions, and that TCP 135 is reachable. On hardened servers, someone usually enabled "RPC Endpoint Mapper Client Authentication" without opening the right ports.

netsh advfirewall firewall show rule name=all | findstr /i rpc

Error after a Windows Update

Recent cumulative updates have changed RPC endpoint security on Server 2016 and 2019. If the error started right after patching, check the System event log for Microsoft-Windows-DistributedCOM event 10010 and roll back the specific KB. Don't roll back the whole month — target it.

WMI or DCOM workloads failing with 0xC0020043

This is almost always a permissions issue on the DCOM identity. Open dcomcnfg, find the app under Component Services → Computers → My Computer → DCOM Config, and reset the identity to "The interactive user" or a known service account. If it says "The launching user" and there's no interactive session, you get exactly this error.

Cluster environments

On failover clusters, RPC errors after a node move usually mean the cluster network name resource's SPN is stale. Run cluster res "Cluster Name" /check /fix and verify DNS.

Prevention

• Don't shrink the dynamic port range. Leave the Windows default alone unless a vendor has explicitly tested a smaller range.
• Monitor RpcEptMapper and RpcSs service state. A single monitor that alerts on service stop will catch this before users do.
• Watch handle leaks on line-of-business apps. If a process climbs past 10,000 handles, it's eventually going to take RPC down with it.
• Keep TCP 135 and the dynamic port range open internally. Full-stop blocking dynamic RPC ports is a self-inflicted wound.
• Schedule reboots. Yes, really. Windows Server doesn't leak RPC bindings forever, but long uptimes (400+ days) make this error more likely.

If you've done all of the above and it's still throwing 0xC0020043, grab a network capture on the client and server simultaneously. The RPC runtime is telling you something internal broke — the packet trace will show which side hung up first, and that tells you where to aim the next fix.