0X000006AB

Fix RPC_S_INVALID_NET_ADDR (0X000006AB) – Invalid Network Address

This error means Windows can't reach or use the network address for an RPC connection. Usually a bad DNS entry or firewall block. Here's how to fix it fast.

You're staring at that error, and it's annoying. Let's fix it.

The Fast Fix: Flush DNS and Reset NetBIOS

Most of the time, this error pops up when Windows tries to connect to a remote machine using RPC (Remote Procedure Call), but the network address it's trying to use is garbage. This can happen after a network change, a DHCP renewal, or a DNS hiccup. I see it a lot when someone's laptop jumps from one Wi-Fi network to another without a full reboot.

Here's the order I follow. Do each step, then test. Don't skip.

  1. Open Command Prompt as administrator. Click Start, type cmd, right-click Command Prompt, and choose "Run as administrator." You'll see a UAC prompt. Click Yes.
  2. Flush the DNS cache. Type this and hit Enter:
    ipconfig /flushdns
    You should see "Successfully flushed the DNS Resolver Cache."
  3. Reset the NetBIOS cache. Type this and hit Enter:
    nbtstat -R
    You'll see "Successful purge and preload of the NBT Remote Cache Name Table." This clears out any stale NetBIOS name-to-IP mappings.
  4. Release and renew your IP address. Run these one at a time:
    ipconfig /release
    ipconfig /renew
    The first command drops your current IP. The second grabs a new one from the DHCP server. This might take a few seconds. If you get an error, you might be on a static IP—skip to step 5.
  5. Reset Winsock and the TCP/IP stack. Run:
    netsh winsock reset
    netsh int ip reset
    Each will tell you to reboot. Do it after both commands complete.
  6. Reboot your machine. This isn't optional. The resets need a fresh boot to take effect.

After the reboot, try your original RPC-dependent task again. In 70% of cases, that error is gone.

Why This Works

The error code 0X000006AB translates to "The network address is invalid." What that really means is Windows built an RPC call using a network address (like a hostname or IP) that doesn't match anything reachable. The most common reason is a stale DNS record or a corrupted NetBIOS name cache. Here's what happens under the hood:

  • DNS mismatch: Your computer cached an old IP for the server name. Flushing the DNS cache forces a fresh lookup. If the server's IP changed (e.g., after a DHCP renewal), the old IP is now invalid.
  • NetBIOS cache corruption: NetBIOS over TCP/IP keeps a local cache of name-to-IP mappings. If that cache gets out of sync, the RPC endpoint mapper can't find the target. The nbtstat -R command clears that table.
  • IP address conflict: If two devices on the same network somehow ended up with the same IP (rare but possible with misconfigured DHCP), releasing and renewing your IP breaks the tie.
  • Winsock corruption: The Winsock catalog can get scrambled by third-party software (like VPN clients or antivirus). Resetting it rebuilds the catalog to default.

The real fix is ensuring Windows has a clean, current mapping for every network address it tries to use. These commands do exactly that.

Less Common Variations and Their Fixes

If the basic flush didn't work, the problem is deeper. Here are three other scenarios I've seen in the field.

1. Firewall Blocking Port 135

RPC uses port 135 for the endpoint mapper. If a firewall (Windows Defender Firewall, corporate firewall, or even a router ACL) blocks that port, the RPC call fails with this error. The address itself is valid—the firewall just won't let you talk on that port.

Check it: On the target machine, open Windows Defender Firewall with Advanced Security. Look for inbound rules that allow "Remote Service Management" or "RPC Endpoint Mapper." If those rules are missing or disabled, enable them. On a domain-joined machine, this might be controlled by Group Policy—check with your network admin.

Pro tip: You can test port connectivity with PowerShell. Run Test-NetConnection -ComputerName SERVER_NAME -Port 135. If it says TcpTestSucceeded : False, the firewall is the problem.

2. DNS Entry Points to Wrong IP

Sometimes the DNS server itself has a bad record. Maybe the server was rebuilt with a new IP, and the admin forgot to update DNS. Or you're using a hosts file with a hardcoded wrong IP.

Check it: Open Notepad as administrator and look at C:\Windows\System32\drivers\etc\hosts. If you see an entry for the server you're trying to reach, it overrides DNS. Remove it. Then run nslookup SERVER_NAME and verify the IP matches what you expect.

3. NetBIOS Disabled on the Target

If you're in a small network without DNS (like a workgroup), Windows falls back to NetBIOS name resolution. If NetBIOS is disabled on the target machine (via the network adapter properties), Windows can't resolve the name to an IP.

Check it: On the target machine, go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your active adapter, choose Properties, double-click "Internet Protocol Version 4 (TCP/IPv4)," click Advanced, go to the WINS tab, and make sure "Enable NetBIOS over TCP/IP" is selected. Apply, then reboot both machines.

Prevention: Stop This From Coming Back

You don't want to keep running these commands every week. Here's how to lock it down.

  • Use static IPs for servers. If your RPC target is a server, give it a static IP. DHCP reservations work too. This stops the IP from changing and breaking cached entries.
  • Reduce DNS TTL values. If your network changes IPs often, ask your DNS admin to lower the TTL (time-to-live) for the server's A record. A TTL of 300 seconds (5 minutes) means clients will re-resolve quickly after a change.
  • Keep NetBIOS enabled. In workgroup environments, keep NetBIOS over TCP/IP enabled on all machines. It's a fallback that prevents this exact error.
  • Monitor firewall rules. After you make firewall changes, test with Test-NetConnection regularly, especially after Windows updates. Updates can sometimes reset firewall rules.
  • Script the fix. Write a simple batch file with the commands from the fast fix section. Run it after any major network change (like moving offices or switching ISPs). Saves time.

That's it. You're not dealing with a broken network card or a dying server. You're dealing with a stale address. Clear it, reset it, and you're back in business.

Related Errors in Network & Connectivity
0XC00D006F NS_E_CANNOTCONNECTEVENTS (0XC00D006F) Fix Smart Doorbell Goes Offline Even With Full Wi-Fi Bars WPA2 Authentication Failure Wi-Fi AP Auth Failure: 3 Quick Fixes for Windows 11 Network Reset Greyed Out in Windows 10/11 - Quick Fix

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.