Fix RPC_S_INVALID_BINDING (0x000006A6) – Stale Binding Handle

This error means a remote procedure call tried to use a stale or wrong binding handle. It's nearly always a mismatch between client and server RPC endpoints.

When You'll See This Error

You're on a Windows Server 2016 or 2019 box, running a remote management tool like wmic or a DCOM-based app. Or you're trying to mount a DFS share from a domain controller. Suddenly you get RPC_S_INVALID_BINDING (0x000006A6). The exact message reads "The binding handle is invalid." It usually pops up after a reboot or a network change. I've seen this most often when a client has cached an old RPC binding to a server that's been restarted or had its RPC service bounce.

Root Cause in Plain English

RPC works by setting up a "binding handle" — think of it as a temporary session ID between a client and a server's RPC endpoint. That handle includes the server's IP, port, and a unique endpoint number. If the server restarts, or the RPC service (RpcSs) on the server gets recycled, that endpoint number changes. The client doesn't know that and tries to reuse the old handle. The server says, "Nope, that handle is invalid." That's your 0x000006A6.

The culprit is almost always a stale cache on the client side. Could also be a firewall that's killing idle RPC connections, or a load balancer that's directing traffic to a different server than the one that created the binding handle.

The Fix: Step-by-Step

Restart the RPC service on the client. Not the server — the client. Open an admin command prompt and type:
```
net stop rpcss && net start rpcss
```
This clears all cached binding handles on that machine. If you can't stop it (it's a critical service), just reboot the client. I know, reboot is the lazy fix, but it works here.
Flush the RPC endpoint mapper cache. Some stubborn handles stick around. Run:
```
rpcdump.exe /flush
```
If you don't have rpcdump.exe, grab it from the Windows SDK or use PowerShell:
```
Get-WmiObject -Class Win32_Process | Where-Object { $_.Name -eq 'svchost.exe' -and $_.ProcessId -ne (Get-Process -Id $pid).Id } | Stop-Process -Force
```
That's a bit nuclear, but it kills all orphaned RPC processes.
Check the server's RPC endpoint. On the server that the client is connecting to, verify that the RPC service is actually running:
```
sc query RpcSs
```
If it's stopped, start it: net start RpcSs. Then check the endpoint mapper is listening:
```
netstat -ano | findstr :135
```
Port 135 should be listening. If not, you've got a bigger problem — usually a misconfigured firewall or a corrupted RPC stack.
Rebuild the binding handle from scratch. On the client, in PowerShell or CMD, explicitly disconnect and reconnect the RPC binding. For example, with WMI:
```
wmic /node:ServerName /user:Domain\User /password:Pass process list
```
This forces a fresh binding negotiation. The error should disappear immediately.
If it's a DFS issue, clear the DFS client cache. On the client, run:
```
dfsutil /purgemupcache
```
Then dfsutil /pktflush. This wipes out any stale RPC bindings related to DFS referrals.

Still Failing? Check These

Firewall rules. Make sure the Windows Firewall (or your third-party one) isn't blocking RPC dynamic ports. RPC uses port 135 for the endpoint mapper, then a high port range (49152-65535 on Server 2008 and later). If you've locked down ports, you need to open that range or configure RPC to use a static port.
DNS and NetBIOS. If the client is resolving the server's name to a different IP than the one that established the binding, you'll get this error. Run nslookup ServerName and compare with ping ServerName. If they differ, fix DNS first.
Time sync. Kerberos relies on time. If the client and server clocks are more than 5 minutes apart, the RPC authentication will fail. Check w32tm /query /status on both sides.
Check for duplicate SPNs. If the server's service principal name is duplicated in Active Directory, RPC authentication gets confused. Run setspn -X from a domain controller to find duplicates.

One more thing: I've seen this error on virtual machines after a live migration (VMware vMotion or Hyper-V Live Migration). The VM's network state gets transferred, but the RPC binding handles don't survive the move. If you're running a cluster or load-balanced setup, you might need to restart the RPC service on the VM after every migration. Talk to your virtualization team.

That's the full playbook. 90% of the time, step 1 or step 2 fixes it. The other 10% is a deeper infrastructure issue — DNS, firewalls, or time sync. Don't waste time rebuilding the server or reinstalling apps. This isn't a corruption problem. It's a stale-session problem. Treat it like one.