RPC_NT_NO_BINDINGS (0XC0020013) – No Bindings on Server

What triggers this error

You'll see RPC_NT_NO_BINDINGS (0XC0020013) when a program tries to call a remote procedure but the RPC runtime can't find an active binding handle. I've seen this most often in two scenarios: after a server reboot when a legacy app starts before the RPC service is fully up, or when a client machine tries to connect to a server that's had its firewall changed. The error text literally says "There are no bindings" — meaning no transport or endpoint has been registered for the interface the client wants.

Cause 1: The RPC service isn't running (most common)

This is the first thing I check. If the Remote Procedure Call (RPC) service is stopped or set to manual, nothing works. On Windows Server 2019 and 2022, this service should be running and set to Automatic start. Same for Windows 10 and 11 Pro.

1. Press Win + R, type services.msc, hit Enter.
2. Scroll down to Remote Procedure Call (RPC). It's listed alphabetically.
3. Check its status. If it says Stopped, right-click it and choose Start.
4. Double-click it. Set Startup type to Automatic. Click Apply, then OK.
5. After this, you should see the status change to Running. If it doesn't start, you may have a corrupted system file — run sfc /scannow from an admin command prompt.

One tip: if the RPC service is already running but the error persists, restart it. Right-click → Restart. Then try your app again. I've had cases where a hung binding leaked and a quick restart cleared it.

Cause 2: Firewall blocking RPC endpoints (port 135 and dynamic ports)

RPC uses port 135 for the endpoint mapper. If that's blocked, the client can't ask "who handles interface X?" and you get 0XC0020013. But that's just the start — the actual RPC traffic uses dynamic ports in the range 49152-65535 (Windows Vista/2008 and later) or 1025-5000 (older systems). If those are blocked, bindings won't establish.

Here's how to check and fix it:

1. Open Windows Defender Firewall with Advanced Security (search for it in Start).
2. Click Inbound Rules on the left.
3. Look for Remote Procedure Call (RPC) or COM+ Remote Administration rules. They should be enabled (Enabled column = Yes).
4. If you don't see these rules, you can create a custom rule: New Rule → Port → TCP → Specific local ports: type 135 → Allow the connection → apply to Domain, Private, Public → name it RPC Endpoint Mapper.
5. For dynamic ports, you don't need to open all of them. Instead, restrict RPC to a smaller range on the server using the registry, then open only that range in the firewall. This is the approach I prefer for production servers.

To restrict RPC ports:

reg add "HKLM\SOFTWARE\Microsoft\Rpc\Internet" /v "Ports" /t REG_MULTI_SZ /d "50000-50255" /f
reg add "HKLM\SOFTWARE\Microsoft\Rpc\Internet" /v "PortsInternetAvailable" /t REG_SZ /d "Y" /f
reg add "HKLM\SOFTWARE\Microsoft\Rpc\Internet" /v "UseInternetPorts" /t REG_SZ /d "Y" /f

Then open ports 50000-50255 TCP in the firewall. Reboot the server. This stabilizes RPC bindings and makes firewall management a lot cleaner.

Cause 3: DCOM permission issues or misconfigured application identity

Some applications rely on DCOM (Distributed COM) to register their RPC interfaces. If the DCOM configuration is wrong, the binding never gets registered. This is particularly common with custom in-house apps or older line-of-business software.

1. Open Component Services (search dcomcnfg in Start).
2. Expand Component Services → Computers → My Computer → DCOM Config.
3. Find the application that's failing. If you don't know which one, look for any that has a yellow warning icon or says "not registered".
4. Right-click it → Properties → go to the Identity tab.
5. By default, it's set to The launching user. If the app runs under a service account, switch to This user and enter that account's credentials. Click Apply.
6. Go to the Security tab. Under Launch and Activation Permissions, click Edit. Make sure the user account running the app has Local Launch and Local Activation permissions. Add it if missing.
7. Click OK all the way out.

After changing identity or permissions, restart the RPC service or reboot the server. I've seen this fix errors that persisted through multiple RPC restarts, especially when the app was using custom RPC interfaces registered via DCOM.

Quick-reference summary table