RPC_S_INVALID_STRING_BINDING (0x000006A4) Fix: 3 Causes

1. DNS Resolution Failure – The Usual Suspect

Nine times out of ten, this error happens because the client can't resolve the server's hostname to an IP. The RPC string binding contains a hostname, and if DNS fails, the string is garbage. Last month a client's file server started throwing this error across the board – turns out their internal DNS server had a stale A record pointing to an old IP.

Fix: Test and Repair DNS Resolution

1. Open Command Prompt as admin.
2. Run nslookup server-hostname. Replace server-hostname with the actual server name from the error.
3. If it returns an IP that's wrong or times out, you've found the issue.
4. Flush DNS cache: ipconfig /flushdns
5. Clear ARP cache: arp -d *
6. Update the DNS record on your DNS server, or add a static entry in the client's C:\Windows\System32\drivers\etc\hosts file for a quick fix.

Skip the hosts file trick for anything permanent – it's a band-aid. Fix your DNS server.

2. Misconfigured RPC Endpoint Mapper

Sometimes DNS is fine, but the RPC endpoint mapper on the server has a bad entry. The client sends a request to port 135 (EPM), but the mapper returns an invalid binding string – often because the service isn't actually listening on the port it claims. I saw this with a print server where the Spooler service had crashed and restarted, but the EPM didn't update its records.

Fix: Restart the RPC Service and Clear EPM Cache

1. On the server, open Services.msc.
2. Find Remote Procedure Call (RPC). Right-click and Restart.
3. Also restart RPC Endpoint Mapper – it's listed as a separate service on some versions.
4. Run net stop rpcss && net start rpcss from an admin prompt to force a clean cache.
5. Test the client connection again.

If the error persists, reboot the server. It's blunt but it cleans the EPM cache completely.

3. Corrupt RPC State or Firewall Blocking Dynamic Ports

RPC uses a range of dynamic TCP ports (default 1024-5000, or 49152-65535 on modern Windows). If a firewall blocks those ports, the binding string gets mangled because the RPC runtime can't negotiate a connection. I had a client using a third-party firewall that only allowed port 135 – everything else was dropped. The client got 0x000006A4 intermittently.

Fix: Verify Firewall Rules and Reset RPC

1. Check your firewall logs for blocked ports in the dynamic range.
2. If using Windows Firewall, ensure Remote Volume Management and Remote Service Management inbound rules are enabled (they include RPC dynamic ports).
3. If you need to limit ports, set a static RPC port range: netsh int ipv4 add excludedportrange protocol=tcp startport=50000 numberofports=1000 – but only do this if your firewall requires it.
4. As a last resort, reset the RPC stack: netsh winsock reset and reboot.

Quick-Reference Summary Table

If none of these fix it, you're likely dealing with corrupt system files – run sfc /scannow and dism /online /cleanup-image /restorehealth. But stick with the top three first. They cover 95% of cases I've seen.