RPC_S_CALL_FAILED (0X000006BE) – What Actually Fixes It
This RPC failure usually hits when a domain controller or server can't talk to one another. Most of the time, it's DNS or a dead RPC service. Here's what I see in the real world.
1. DNS Misconfiguration – The Real Culprit 80% of the Time
I've been walking into small businesses for years where the server admin thought "DNS just works". Then they get this error when trying to join a machine to the domain, or worse, a domain controller replication fails. The error code is 0X000006BE, which translates to RPC_S_CALL_FAILED – the RPC call didn't even get a chance to start because the name resolution bombed.
Here's what happens: Your server (say, a Windows Server 2022 box) needs to talk to the domain controller. It does a DNS lookup for the DC's GUID-based SRV record. If that record is missing, stale, or pointing to a wrong IP, the RPC call fails with this exact code. I had a client last month whose print queue server couldn't authenticate to the DC because someone had manually set a static DNS entry that pointed to a retired server. Took me 10 minutes to find, but they'd been fighting it for two days.
The fix: Check the DNS server's forward lookup zones. Make sure the _msdcs zone has all the SRV records for your domain controllers. Run this on the DC that holds the PDC role:
nslookup -type=srv _ldap._tcp.dc._msdcs.yourdomain.local
If you get back no records, or stale ones, you need to fix registration. The quickest way is to force the DC to re-register its DNS records:
ipconfig /registerdns
Then wait a couple minutes and rerun the nslookup. If it's still broken, check that your DC's network adapter points to itself for DNS (or to a secondary DC) – not to an external DNS like 8.8.8.8. That's a rookie mistake I see all the time.
2. RPC Service Isn't Running – Obvious but Overlooked
This one sounds stupid, but I've seen it twice this year: the Remote Procedure Call (RPC) service gets set to Manual or Disabled by a well-meaning security audit. Or a Windows update kills it. When the RPC service is off, 0X000006BE is guaranteed to show up. You can't do anything cross-machine – no file shares, no DNS dynamic updates, no DCOM.
The fix: Open Services.msc. Look for "Remote Procedure Call (RPC)". It should be running and set to Automatic. If it's stopped, right-click and Start. Then check its dependencies: the RPC Endpoint Mapper and DCOM Server Process Launcher must also be running. Set all three to Automatic and restart the server if you can. If you can't restart, at least ensure the service is started and stays that way.
If the service keeps stopping, check the System event log for event ID 7034 or 7031. That can point to a corrupted RPC endpoint. In that rare case, you might need to run System File Checker:
sfc /scannow
But 9 times out of 10, just starting the service and setting it to Automatic fixes it.
3. Firewall Blocking RPC Dynamic Ports
RPC loves using high ports – 49152-65535 on modern Windows. If you've got a firewall between your servers, or Windows Firewall is overly restrictive, the RPC call can fail with 0X000006BE. This shows up most often when you have a workgroup server talking to a domain controller, or when you've got two DCs on different subnets.
The fix: On the server receiving the RPC call (usually the DC), enable inbound Rule for RPC. Open Windows Firewall with Advanced Security. Look for "Remote Service Management (NP-In)" and "Remote Service Management (RPC-In)". They should be allowed for Domain profile. If you are not on a domain, you might need to allow the RPC Endpoint Mapper (TCP 135) and then a wide range of dynamic ports. I don't like opening the full dynamic range unless I have to. Instead, I configure RPC to use a fixed port range – less messy with firewalls.
To set a fixed port range, use Group Policy or regedit on the DC:
HKLM\SOFTWARE\Microsoft\Rpc\Internet -> Key: Ports (REG_MULTI_SZ)
Data: 5000-5100
Key: PortsInternetAvailable (REG_SZ)
Data: Y
Key: UseInternetPorts (REG_SZ)
Data: Y
Then open those specific ports (5000-5100) plus TCP 135 in your firewall. You'll need to restart the server. This is more controlled and won't mess with other apps.
I also check for third-party AV firewalls. Had a client whose Trend Micro OfficeScan was blocking RPC traffic between two DCs. Disabled the firewall module for a test – error disappeared. Then we added an exclusion for the DC's IPs.
Quick-Reference Summary Table
| Cause | Symptom | Fix |
|---|---|---|
| DNS misconfiguration | SRV records missing or wrong | Run ipconfig /registerdns and verify _msdcs zone |
| RPC service stopped | RPC service set to Manual or Disabled | Set to Automatic, start service, check dependencies |
| Firewall blocking ports | RPC calls fail between subnets | Allow TCP 135 and dynamic ports (or set fixed range) |
Was this solution helpful?