RPC_S_ADDRESS_ERROR (0X000006E8) Quick Fix Guide

Quick answer

Restart the RPC service (net stop RpcSs then net start RpcSs) and flush DNS cache (ipconfig /flushdns). If it persists, check Windows Firewall allows RPC dynamic ports (49152-65535) and verify DNS resolution for the target server.

What's happening here?

Error 0x000006E8—RPC_S_ADDRESS_ERROR—means the RPC runtime can't translate a server name or address during a remote call. I've seen this most often when a client tries to connect to a domain controller or file server, and the DNS lookup returns a stale or wrong IP. Happens a lot after network changes, like moving servers to a new subnet without clearing DNS cache. Or when a firewall blocks the high ports RPC uses by default (49152-65535 on modern Windows). The error text says "addressing error" but the root cause is almost always name resolution, not a network address format issue.

Fix steps

Restart the RPC service — This clears transient state. Open an admin command prompt and run:
```
net stop RpcSs && net start RpcSs
```
Also restart the RPC Locator service if it's running:
```
net stop RpcLocator && net start RpcLocator
```
Flush DNS cache — Stale records are the #1 trigger. Run:
```
ipconfig /flushdns
```
On a domain controller, also run dnscmd /clearcache or restart the DNS service.
Check DNS resolution — Use nslookup <server_name> to verify the target server resolves to the correct IP. If you see multiple IPs or old ones, update DNS records and wait for replication.
Verify RPC dynamic ports are open — Windows Firewall must allow inbound traffic on ports 49152-65535 (TCP and UDP) for RPC. Also check if a firewall appliance between client and server blocks these. Temporary test: disable Windows Firewall on both ends for 30 seconds (then re-enable) to rule it out.
Check the RPC Endpoint Mapper — The EPM runs on port 135. Make sure it's reachable from the client: telnet <server_IP> 135 or Test-NetConnection -ComputerName <server> -Port 135. If port 135 is blocked, RPC can't start.

Alternative fixes if main steps don't work

Clear the RPC cache manually — Some tools cache endpoint mappings. Stop the RPC service, delete the file C:\Windows\System32\RpcProxy\rpcproxy.dll (it gets rebuilt on service start), then restart the service. I've used this trick on Windows Server 2016 when nothing else worked.
Disable IPv6 — Rare but possible: IPv6 DNS records cause confusion. Temporarily uncheck IPv6 in the network adapter properties and test. If it fixes the issue, you've got a dual-stack DNS problem.
Set a static RPC port range — If your firewall folks are strict, configure RPC to use a specific port range. Run:
```
netsh int ipv4 add excludedportrange protocol=tcp startport=50000 numberofports=10000
```
Then set the RPC port via registry:
```
reg add "HKLM\SOFTWARE\Microsoft\Rpc\Internet" /v "Ports" /t REG_MULTI_SZ /d "50000-60000" /f
```
Reboot. This narrows your attack surface and avoids firewall guesswork.
Check for third-party RPC filters — Antivirus software (especially Symantec, McAfee, or Kaspersky) sometimes intercept RPC traffic. Temporarily disable real-time protection and test. If the error disappears, add an exception for RPC traffic.

Prevention tips

Keep DNS records clean — Run dcdiag /test:dns weekly on domain controllers. Scavenge stale records. I set scavenging to 7 days for dynamic records.
Monitor RPC port usage — Use performance counters like "RPC/Ports Allocated" to spot exhaustion. Add alerts if allocated ports exceed 80% of the dynamic range.
Document network changes — When you move servers or change subnets, force a DNS update and clear cache on all clients. I learned this the hard way after a VLAN migration took down file shares for an hour.
Update firewall rules after OS upgrades — RPC dynamic port range shifted from 1024-5000 (pre-Vista) to 49152-65535 (Vista+). If you're still using old firewall rules, you'll hit this error.

One last thing: if you're on Windows Server 2008 R2 or earlier, the dynamic port range starts at 1025. That's a common gotcha when migrating to newer Windows versions—your firewall rules may still reference the old range. The error 0x000006E8 will taunt you until you update them.