RPC_S_NO_MORE_BINDINGS (0X0000070E) – No more bindings fix

What this error means (and why it pops up)

You're seeing RPC_S_NO_MORE_BINDINGS (0X0000070E) – that's Windows saying "I can't find any more RPC binding handles to give you." Translation: whatever app or service called the RPC runtime, it got back nothing. No endpoint, no interface, nada.

I see this most often on Windows Servers (2016, 2019, 2022) running clustered roles – SQL Server failover clusters, Exchange DAGs, or file server clusters. The trigger is usually a node reboot or a network partition that drops the RPC endpoint mapper's cache. Sometimes a third-party app with a leaky RPC call does it too.

Let's walk through fixes from quick to deep. You can stop at any step that clears it.

Fix 1: Restart the RPC services (30 seconds)

This is the first thing I make every tech do. It sounds dumb, but the Remote Procedure Call (RPC) and RPC Locator services sometimes just glitch out after an overload or a bad network packet. Restarting them flushes the binding cache.

1. Open a Command Prompt as Administrator. Hit Win, type cmd, right-click and pick Run as administrator.
2. Type these two commands, one at a time, hitting Enter after each:

net stop rpcss && net start rpcss
net start RpcLocator

What you'll see: The requested service has been started for both. If rpcss fails to stop, you'll get an error – that's fine, just run net start rpcss anyway.

After that, try your failing app or service again. If the error goes away, you're done. If not, move on.

Fix 2: Check and re-register the RPC endpoint mapper (5 minutes)

When RPC services are running but bindings are missing, the endpoint mapper (port 135) might have stale or corrupted entries. On a cluster or a server with many dynamic RPC endpoints, this happens more than Microsoft admits.

Here's what I've found works: force a re-registration of all RPC interfaces.

1. Open an elevated PowerShell (Admin).
2. Run this to check if the endpoint mapper is listening:

Get-Process -Name svchost | Where-Object { $_.Modules.ModuleName -contains 'rpcepmap.dll' }

What you'll see: One or more svchost PIDs should show. If none appear, the endpoint mapper isn't loaded. In that case:

1. Restart the RPC service again from Fix 1, then run the check again.
2. If still no PIDs, manually start the endpoint mapper with:

start-service RpcEptMapper

Expected: Status: Running in the output.

Then, re-register all known RPC interfaces by restarting the dependent services. The easiest way is to reboot just those services:

Get-Service | Where-Object { $_.DependentServices -contains (Get-Service RpcSs) } | Restart-Service -Force

This restarts every service that relies on RPC – things like DHCP Client, DNS Client, and your clustered roles. After that, test your application again.

Fix 3: Rebuild the cluster RPC binding configuration (15+ minutes)

If you're still getting 0X0000070E, the problem is almost certainly in a Windows Failover Cluster. The cluster service manages its own RPC binding handles, and when a node loses and regains quorum, those handles can go missing.

Real-world scenario I've fixed: A SQL Server 2019 cluster on Windows Server 2022. After a patch reboot, the secondary node couldn't start the SQL role. Event logs showed this exact RPC error. No amount of RPC service restarts helped. The fix was to reset the cluster's RPC endpoint list.

Here's the proper way:

1. Open Failover Cluster Manager. Connect to your cluster.
2. Right-click the cluster name in the left pane, choose More Actions, then Reset Cluster Node. This forces the node to drop and re-establish its RPC bindings with the other nodes.
3. If that option is grayed out, open an elevated PowerShell and run:

Stop-ClusterNode -Node $env:COMPUTERNAME
Start-ClusterNode -Node $env:COMPUTERNAME

What you'll see: The node stops all cluster services, then starts them fresh. The cluster log will show new RPC bindings being created. After the node is back online, try bringing the role online again.

Pro tip from my years on help desk: If the cluster still shows the error, delete and re-create the cluster's RPC endpoint by clearing the cluster registry keys. Don't do this lightly – it can break things. But when nothing else works, here's the safe path:

# Backup cluster registry first
reg export "HKLM\Cluster\RPC" "C:\backup_cluster_rpc.reg"
# Delete the RPC subkey (cluster will rebuild it)
reg delete "HKLM\Cluster\RPC" /f

Then restart the cluster service on all nodes: Stop-Service ClusSvc; Start-Service ClusSvc on each node one at a time. After the last node reboots, the cluster will regenerate the RPC bindings automatically.

When none of this works

If you've done all three fixes and still see 0X0000070E, look at the application itself. I've seen custom apps that use RPC with hardcoded binding strings that go stale. Check the app's logs for any reference to a specific interface GUID (something like {12345678-1234-1234-1234-123456789012}). That tells you which RPC interface it's trying to call. If the server doesn't export that interface, you're beyond what RPC fixes can solve – you need a developer to look at the app's RPC client code.

Also, scan for malware. Some worms mess with RPC bindings. I caught a cryptominer once that was corrupting the RPC endpoint mapper on a server farm. Ran a full Defender scan and a Sysinternals Autoruns check – found the bad DLL in AppInit_DLLs. Cleaned it, and the RPC errors vanished.