Fix STATUS_ND_QUEUE_OVERFLOW 0XC000A011 on Windows

You're Here Because Your Windows Machine Keeps Hitting This Error

Yeah, I get it. 0XC000A011 pops up, your network stack goes sideways, and you're staring at a crash dump or a hung connection. I've seen this on Windows 10, 11, Server 2019, Server 2022 — basically any modern NT-based OS. The culprit is almost always the Neighbor Discovery (ND) queue getting hammered and overflowing. Let me save you some time.

The Fix: Three Commands and a Driver Update

Don't bother with deep registry spelunking or reinstalling Windows. 9 times out of 10, this is either a bad NIC driver or a misconfigured IPv6 neighbor cache. Here's the sequence I use:

Update your network adapter driver. Go straight to the manufacturer's site (Intel, Realtek, Broadcom — whoever made the chip). Windows Update drivers are often outdated or buggy. Use the latest stable version from 2023 or later.
Reset the IPv6 stack. Open an elevated Command Prompt (Admin) and run:
```
netsh int ipv6 reset
```
Then reboot.
Clear the neighbor cache and set a sane limit. Still in admin prompt:
```
netsh int ipv6 delete neighbors
netsh int ipv6 set global neighborcachelimit=256
```
The default limit is too high — it lets the queue grow until it explodes. 256 is plenty for most LANs.

That's it. Reboot again if you skipped step 2. I'd say 80% of cases resolve with just these steps.

Why This Works

The ND queue is a kernel-side buffer that stores IPv6 neighbor solicitation and advertisement packets. When the NIC driver or IPv6 stack misbehaves — say, a flaky driver doesn't process ND packets fast enough, or a burst of IPv6 traffic (from a bad router or a misconfigured app) overwhelms the queue — the buffer overflows. That's 0XC000A011.

Driver update fixes bugs in the NIC's interaction with the ND queue. Some Realtek drivers from 2020–2021 had a known issue where they'd drop ND packets under load.
Resetting IPv6 flushes the cache and resets the stack's internal timers and buffers.
Lowering the cache limit prevents the queue from growing so large that it hits the overflow threshold. Think of it like setting a smaller bucket — it overflows less because it fills slower relative to processing.

Less Common Variations of This Issue

Not every case is a simple driver problem. Here are the edge cases I've run into:

1. Bad Router Sending Floods of ND Packets

Some cheap home routers or older enterprise gear (looking at you, certain Cisco Small Business models) have bugs where they resend neighbor solicitations on every link-state change. If you see this error consistently on a specific subnet, check the router logs. The fix is usually a firmware update or replacing the router.

2. Anti-virus or Firewall Interference

I've seen McAfee Endpoint Security and Palo Alto Traps (now Cortex XDR) intercept ND packets and corrupt the queue. Temporarily disable the network protection feature, test, and if it stops, add an exclusion for IPv6 ND traffic.

3. Hyper-V or VMware Virtual Switches

Virtual environments can hit this if the virtual switch driver is old. Update your hypervisor's integration tools. On VMware, that means the VMXNET3 driver. On Hyper-V, the Microsoft Network Adapter driver. Also check that you haven't assigned too many virtual NICs to one VM — each one creates its own ND queue.

4. IPv6 Tunneling or Transition Technologies

If you're using ISATAP, 6to4, or Teredo, they can amplify ND traffic. The quick test: disable them with:

netsh int ipv6 set teredo disabled
netsh int ipv6 set isatap disabled
netsh int ipv6 set 6to4 disabled

Then reboot and see if the error stops. Most enterprises don't need these anyway.

Prevention: Stop It From Coming Back

Once you've fixed it, here's how to keep it from reoccurring:

Keep NIC drivers updated. Check for updates quarterly. I set a reminder in my ticketing system.
Limit the neighbor cache globally. The 256 limit from above is a good permanent setting. Make it stick by adding it to a startup script or Group Policy.
Monitor router ND behavior. If you manage the network, enable logging for ND events on the router. A sudden spike in neighbor solicitations often precedes the error.
Prefer IPv4 where possible. If IPv6 isn't critical to your environment, you can disable it entirely. That's a nuclear option, but it eliminates the error. I don't recommend it unless you've verified IPv6 isn't needed.

One last thing: If you see 0XC000A011 in a minidump and the machine blue-screens, the fix is the same. The ND queue overflow triggers a bugcheck. Don't chase the wrong rabbit — it's still the ND queue.