Fix Error 0XC000005E: No Logon Servers Available

You're sitting at a user's desk, they're staring at a login screen that won't accept their password. The exact error pops: STATUS_NO_LOGON_SERVERS (0XC000005E) – No logon servers are currently available to service the logon request. This happens most often on a laptop that was just woken from sleep in a different office, or a desktop that lost network connectivity overnight. I've seen it when a Wi-Fi driver decides to take a nap after a Windows update, or when a VPN drops mid-session and the machine tries to re-authenticate.

Root cause is simple: Windows is trying to validate your domain credentials against a domain controller (DC). It can't find one. That could be because the network is down, DNS is misconfigured, or the DC itself is unreachable. The machine isn't stupid—it knows your password, but it refuses to let you in without a DC to stamp it. Unless you've got cached credentials, you're locked out.

Quick check: can you even reach a DC?

Before you go pulling your hair out, verify the basics. If you're on the same subnet as your DC, ping it. If you're remote, check your VPN. But the real culprit in 80% of cases is DNS. Windows locates DCs via DNS SRV records, not by magic. If your DNS points to the wrong server or the records are stale, you get this exact error.

Here's what I do, step by step, when I hit this on a client machine.

Fix it: numbered steps

Check physical network connection. Look at the network icon. Are you connected? Run ipconfig /all and see if you have an IP that makes sense. If you're on DHCP and got a 169.254.x.x address, that's an APIPA—no DHCP server reachable, which means no DC either. Fix your network first.
Verify DNS settings. In the same ipconfig output, look at the DNS servers. They should be internal IPs (like 10.0.0.10), not 8.8.8.8. If they're wrong, set them manually: open Network Adapter settings > IPv4 > Properties, and put in your DC's IP as preferred DNS. I've had clients where the router was handing out public DNS, and that breaks everything.
Test DC discovery. On the stuck machine, run this to see if it can find a DC:
```
nltest /dsgetdc:yourdomain.com
```
Replace yourdomain.com with your actual domain. If it returns an error, you've confirmed the problem. You can also ping your DC by name—not just IP—to test DNS resolution.
Check if cached credentials will work. If the user has logged in before on this machine, Windows stores a hash. Click "Other user" on the login screen, type .\username and the password. That forces a local logon using cached credentials. It won't give network access, but it gets you in to fix things. I had a client last month whose DC firewall blocked RPC, and this was the only way in.
Flush DNS and re-register. If you suspect stale records, run from an elevated command prompt:
```
ipconfig /flushdns
ipconfig /registerdns
```
Then restart the Netlogon service: net stop netlogon && net start netlogon. That forces a fresh discovery attempt.
Reboot the router or switch. Seriously. I've seen a flaky switch port cause this for a whole office. One client had a dying NIC that would only work after a reboot—the machine would lose DC access every few hours.

When the fix isn't on the client

If you've done all that and still stuck, the problem might be on the DC side. Check that the DC is actually running and reachable from another machine. Look at Event Viewer on the DC for NTDS errors. Common culprits: clock skew (time off by more than 5 minutes), firewall blocking RPC ports (135, 49152-65535), or the DC's own DNS service crashed.

Also, if this happens right after a domain controller was decommissioned but clients still point to its DNS, you'll get this. Update your DHCP scope to hand out the new DC's IP as DNS.

Still failing? Try this

If the error persists after all steps, consider:

Check if the machine's time is off. Run w32tm /resync after setting time manually. Kerberos is picky—more than 5 minutes off and it'll refuse to talk.
Temporarily disable IPv6. Sometimes IPv6 DNS is misconfigured. In adapter settings, uncheck IPv6 and test. I've seen that fix a bizarre case where IPv6 was pointing to a dead DC.
Look at the network profile. If it's set to "Public," Windows may block your own LAN. Change it to "Private" or "Domain" if you can.
Restart the workstation. A full shutdown and boot clears up more than you'd think, especially after driver updates.

This error is almost always a network or DNS problem, not a Windows one. Start there and you'll have it fixed before lunch.