Fix RPC_S_BINDING_INCOMPLETE (0X0000071B) in 15 Minutes

What's Going On?

You're trying to connect to a server or another machine, and you get the error: RPC_S_BINDING_INCOMPLETE (0X0000071B) — The binding handle does not contain all the required information. It's a lie. The binding handle is fine. What's really broken is the network path or the RPC service on the target machine.

I saw this last month on a client's Server 2019 that couldn't talk to a NAS. Also on a Windows 10 Pro workstation that suddenly couldn't map a drive to a file server. In both cases, the fix was simple once you know where to look.

Follow this order. Don't skip steps unless you're sure. Most people fix it in step 1 or 2.

Fix 1: Quick Network Reset (30 seconds)

This handles temporary glitches. Half the time, that's all it is.

1. Restart both machines. Not just yours. The target server too. Had a client skip this once and waste an hour.
2. Ping the target. Open cmd, run ping [target IP or hostname]. If it fails, you've got a network problem — check cables, Wi-Fi, VLANs.
3. Flush DNS. Run ipconfig /flushdns on your machine. Run ipconfig /registerdns on the target server if you can.

If ping works but the error persists, move on.

Fix 2: Check RPC Services (5 minutes)

0X0000071B often means the Remote Procedure Call (RPC) service on the target machine is stopped or misconfigured. This is common after a Windows update or a security tool killed it.

1. On the target machine, open services.msc.
2. Find Remote Procedure Call (RPC). It should be Running and set to Automatic.
3. Also check RPC Endpoint Mapper and DCOM Server Process Launcher. Both should be running, automatic.
4. If any are stopped, right-click and Start them. Then Restart the RPC Locator service too, just for good measure.

Test your connection again. If it works, you're done. If not, reboot the target and test once more. Had a client where the service started but the binding didn't refresh until a reboot.

Fix 3: Verify Firewall and Ports (10 minutes)

RPC uses dynamic ports (typically 49152-65535) plus the Endpoint Mapper on port 135. A firewall — Windows Defender Firewall or a third-party one — can block this.

1. On the target machine, open wf.msc (Windows Defender Firewall with Advanced Security).
2. Check Inbound Rules for Remote Service Management and Remote Event Log Management. They should be enabled for your network profile (Private/Domain).
3. Also verify that File and Printer Sharing is enabled — it opens the necessary RPC ports.
4. If you have a third-party firewall (Norton, McAfee, etc.), check its logs. It might be silently blocking RPC traffic.
5. To test if the firewall's the issue, temporarily disable the firewall on the target machine (not recommended for production, but good for diagnosis). If the connection works, you've found the culprit.

For Server 2019, I've seen Windows Defender Firewall rules getting corrupted after cumulative updates. Resetting the rules with netsh advfirewall reset (run as admin) fixed it.

Fix 4: DNS Hostname Resolution (15+ minutes)

This is the sneaky one. The error happens when the client can't resolve the target's hostname to a valid IP that matches the server's self-identity. The binding handle includes the server's computer name, but if DNS gives a wrong IP, the RPC endpoint mapper rejects it.

1. On the client machine, open cmd and run nslookup [target hostname]. Does the returned IP match the target's actual IP? If not, you've got a DNS problem.
2. On the target machine, run ipconfig /all and note its IP. Then run nslookup %computername% from the target itself. If it doesn't return its own IP, its DNS registration is broken.
3. To fix: On the target, run ipconfig /registerdns as admin. Then check the computer's DNS suffix in System Properties > Computer Name > Change > More. Make sure it matches your domain or workgroup.
4. If you're in a workgroup without a DNS server, add an entry in the client's C:\Windows\System32\drivers\etc\hosts file. Use this format:

   [target IP] [target hostname]

   For example:

   192.168.1.100 SERVER01

5. Flush DNS on the client again: ipconfig /flushdns.

Had a client where the server's hostname was SERVER01 but DNS returned 192.168.1.50 (which was a different machine). The RPC binding failed because the server's self-identity didn't match. A simple DNS record fix resolved it.

Fix 5: Registry Tweak for RPC Port Range (Advanced, 15+ minutes)

Sometimes the dynamic port range is too narrow or conflicting. This is rare, but I've seen it on heavily firewalled servers.

1. On the target machine, open regedit as admin.
2. Go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\Internet. If Internet key doesn't exist, create it.
3. Create a new DWORD (32-bit) named Ports. Set its value to 49152-65535 (or a specific range like 50000-51000 if your firewall requires it).
4. Create another DWORD named PortsInternetAvailable and set it to 1.
5. Create another DWORD named UseInternetPorts and set it to 1.
6. Reboot the target machine.
7. Update your firewall to allow that port range inbound to the target.

This forces RPC to use a predictable port range. Test the connection. If it still fails, the problem isn't the ports.

When All Else Fails

If you've gone through all five fixes and the error persists, it's time to look at the application making the RPC call. Some software — especially legacy apps or custom in-house tools — might be passing malformed binding handles. Check the event logs on both machines for Application or System errors around the time of the failure. Look for Event ID 5719 (RPC connection failure) or 10009 (DCOM).

I've seen this with an old version of QuickBooks that couldn't handle IPv6. Disabling IPv6 on the server's network adapter fixed it. To do that: open Network Connections, right-click your adapter, Properties, uncheck Internet Protocol Version 6 (TCP/IPv6), and reboot.

You've got this. 0X0000071B is a pain, but it's almost always a network or service issue. Fix those, and you're back in business.