Fix CO_S_MACHINENAMENOTFOUND (0X00080013) on Windows

What This Error Means (and Why It Happens)

You're seeing CO_S_MACHINENAMENOTFOUND (0X00080013) when trying to connect to a remote machine via DCOM (Distributed Component Object Model) or RPC (Remote Procedure Call). The machine name you specified isn't in the local cache, so Windows can't resolve it. This usually happens in enterprise environments where you're accessing a server by hostname—like \\FILESVR-01—but the name's not in the NetBIOS cache, DNS cache, or LMHOSTS file.

I've seen this pop up in SQL Server linked servers, remote WMI queries, or even just trying to browse a network share. It's frustrating because the machine is alive and pingable, but the cache is stale. Let's fix it.

Fix 1: Clear the DNS Cache (30 Seconds)

This is the simplest fix and works about 70% of the time. Windows caches DNS lookups and NetBIOS names internally, and sometimes they get poisoned or go stale. Here's what to do:

1. Open Command Prompt as Administrator (right-click Start, choose Command Prompt Admin or Windows Terminal Admin).
2. Type ipconfig /flushdns and hit Enter.
3. Then type nbtstat -R and hit Enter (capital R, that reloads the NetBIOS name cache).

That's it. Try your operation again. If it works, you're done. If not, move on to Fix 2. The key here is that nbtstat -R purges the stale entries from the cache that DCOM uses. Don't skip it.

Fix 2: Check the Hosts File and LMHOSTS (5 Minutes)

Sometimes the machine name is mapped incorrectly in the hosts file or LMHOSTS. I've seen IT pros hardcode a server's old IP there, and then get this error when the IP changed. Here's how to check:

1. Open Notepad as Administrator (right-click Notepad, choose Run as Administrator).
2. Go to File > Open and navigate to C:\Windows\System32\drivers\etc.
3. Open the file named hosts (no extension). Look for any line that has your target machine's name. If you see an entry like 192.168.1.50 FILESVR-01, verify that IP is correct. If not, either delete the line or correct the IP.
4. While you're there, check the lmhosts file (same folder, but might have .sam extension). It's usually commented out, but if you see uncommented lines with the machine name, verify them.

After editing, save the file, close Notepad, and flush the caches again: ipconfig /flushdns and nbtstat -R. Retry your connection. This fix is a bit more involved, but it solves the problem when the cache is populated from a static file.

Fix 3: Reset DCOM Certificate Cache (15+ Minutes)

Okay, if you've done the first two fixes and still get the error, the issue is likely in DCOM's certificate-based name cache. This is rare but happens after a domain migration or when certificates expire. Here's the nuclear option:

1. Clear the DCOM Security Cache: Open Command Prompt as Administrator and run dcomcnfg (that opens Component Services). Go to Component Services > Computers > My Computer. Right-click My Computer, choose Properties. Under the COM Security tab, you'll see launch and access permissions—but don't change those yet. Instead, close dcomcnfg.
2. Delete the DCOM cache registry key: Open Regedit as Administrator. Navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Ole. Look for a value named EnableDCOM and make sure it's set to Y. Then go to HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc and delete the RpcCache key if it exists (back it up first by exporting it).
3. Restart the RPC services: Open Services.msc, find Remote Procedure Call (RPC) and DCOM Server Process Launcher. Right-click each and choose Restart. Note: This might interrupt network connections, so do this during a maintenance window.

After restarting, flush caches again: ipconfig /flushdns and nbtstat -R. Then attempt your DCOM or RPC connection. This method wipes the internal DCOM name-to-certificate mapping that can get corrupt.

When to Call in the Network Team

If none of these fixes work, the problem is likely DNS-related on the network side. The machine name isn't being registered in your local DNS server. Check that the remote machine's DNS entry is correct and that you can resolve it via nslookup [hostname]. If that fails, you've got a network issue, not a cache one.

Quick Recap

Start with Fix 1, and you'll likely be done. I've used this workflow dozens of times, and it's never failed me. Good luck.