0X00000837 Fix: Server Could Not Be Located

I know this error is infuriating

You're trying to connect to a file share or remote server on your Windows Server 2019 machine, and boom—0X00000837 pops up with that vague message: "The server could not be located." You've checked the server name three times, it's on the same subnet, and yet Windows acts like it's on Mars. I hit this a lot with domain controllers that love to forget their own DNS records.

The real fix: Flush DNS and refresh NetBIOS

Skip the 3-hour network trace. In 90% of cases, this error is a stale DNS cache or a corrupted NetBIOS name table. Here's what you do:

Open Command Prompt as Administrator. Press Windows Key + X, choose "Command Prompt (Admin)" or "Terminal (Admin)".
Flush DNS cache. Run this:
ipconfig /flushdns
You should see "Successfully flushed the DNS Resolver Cache."
Reset NetBIOS name cache and re-register. Run:
nbtstat -R (that's capital R)
Then:
nbtstat -RR (capital RR)
Clear ARP cache just in case. Run:
arp -d *
Try connecting again. Use the FQDN of the server (like \\fileserver.contoso.com\share) instead of just the NetBIOS name (\\fileserver\share). This forces DNS resolution and sidesteps WINS if it's flaky.

If the error disappears, you're golden. If not, move to the next section.

Why flushing DNS works here

Error 0X00000837 is a resolution failure. Windows tries to locate the server via DNS first, then falls back to NetBIOS broadcasts, WINS, or LMHOSTS. When the DNS cache holds an outdated or wrong IP (say the server's IP changed after a reboot), the connection fails before it ever reaches the real server. Flushing the cache forces a fresh lookup. The nbtstat -RR command re-registers your own NetBIOS name with the WINS server (if you use one), which helps if the error happened when your machine was the one being searched for.

A common scenario: you're using a DFS namespace and the referral points to a stale server. DNS flush clears the old referral IP, and the new query picks up the correct target. This tripped me up the first time when a DFS link kept pointing to a decommissioned file server.

Less common variations that need a registry tweak

Sometimes the DNS flush isn't enough because Windows is being stubborn about name resolution order. If you're in a network without DNS suffixes properly configured (common in smaller offices or labs), you might need to force Windows to prefer NetBIOS over DNS for short names.

Variation 1: NetBIOS over TCP/IP is disabled

Go to Control Panel > Network and Sharing Center > Change adapter settings. Right-click your active network adapter, choose Properties, double-click Internet Protocol Version 4 (TCP/IPv4), click Advanced, go to the WINS tab, and ensure Enable NetBIOS over TCP/IP is selected. If it was set to "Default" or "Disable", the NetBIOS fallback won't work, and DNS has to do all the heavy lifting—which fails if DNS is misconfigured.

Variation 2: LMHOSTS lookup is missing the server

On the same WINS tab, check Enable LMHOSTS lookup. Then open C:\Windows\System32\drivers\etc\lmhosts in Notepad (as Admin). Add a line for your server like:
192.168.1.50 FILESERVER #PRE #DOM:CONTOSO
The #PRE flag preloads it into the NetBIOS cache on boot. Run nbtstat -R again to reload it immediately.

Variation 3: Registry override for name resolution order

If the error only happens when using NetBIOS names but works fine with FQDNs, you can tweak the registry to prioritize NetBIOS. Open regedit and go to:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters
Create a DWORD (32-bit) named NodeType. Set its value to 1 for B-node (broadcast only) or 2 for P-node (WINS only). Most networks use 4 (mixed mode, H-node). I've seen 0X00000837 vanish after changing from 4 to 1 in small networks without WINS. Reboot or run nbtstat -R to apply.

Prevention: Stop this error from coming back

Once you've fixed the immediate issue, do these three things to prevent a repeat:

Set static DNS entries for critical servers in your DHCP scope or DNS zone. Use a short TTL (like 600 seconds) during maintenance windows so changes propagate fast.
Check your DNS suffix list. In Advanced TCP/IP Settings > DNS, make sure Append parent suffixes of the primary DNS suffix is checked, and add your domain suffix (e.g., contoso.com) to the list. Without this, Windows can't resolve \\fileserver to \\fileserver.contoso.com automatically.
Monitor event logs for Event ID 1103 or 1105 under Microsoft-Windows-DNS-Client/Operational. These log DNS failures that can hint at this error before it bites users.
Update your network driver if you're on Windows Server 2019 with broadcom NICs—there's a known bug where the driver flips NetBIOS off after sleep or a network cable pull. A driver update from the OEM site (not Windows Update) fixed that for me.

That's it. You should now be connected without that 0X00000837 headache. If it still shows up, check your firewall—port 139 (NetBIOS) and 445 (SMB) need to be open between the client and server. But that's rare. Nine times out of ten, it's DNS or NetBIOS cache.