Fix ERROR_NDIS_INVALID_ADDRESS 0x80340022

You've just moved a laptop between networks, or restored a Hyper-V VM, and now something can't talk to anything — with ERROR_NDIS_INVALID_ADDRESS (0X80340022) staring back at you from an event log or app dialog.

Here's the fix, in order. Don't skip steps.

Step 1: Reset Winsock and the IP stack

Open an elevated Command Prompt (right-click, Run as administrator) and run these two commands. Order matters — Winsock first, then the IP stack.

netsh winsock reset
netsh int ip reset

Reboot. Don't skip the reboot; both commands stage registry changes that only apply on the next boot.

Why these two specifically

Winsock reset rebuilds the layered service provider chain — the chain of shims that sit between an app and the TCP/IP driver. When an LSP gets corrupted (usually by a leftover VPN client, an old antivirus, or a proxy tool that uninstalled badly), the socket layer passes a mangled address down to NDIS, and NDIS rejects it as invalid. netsh int ip reset rewrites the HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters and Interfaces keys back to defaults. Any half-written interface config that survived a crash gets cleared.

Step 2: Check for a static IP on the wrong subnet

If step 1 didn't fix it, look at your adapter settings. A very common real-world trigger: you set a static IP of 192.168.1.50/24 on your home network, then carried the laptop into an office that uses 10.0.0.0/24. Windows keeps the static config, the gateway becomes unreachable, and any service trying to bind to that interface fails with 0x80340022 because the requested address isn't routable on any live interface.

ipconfig /all

Look for any adapter with a static IP that doesn't match your current subnet. Set it back to DHCP:

netsh interface ip set address name="Ethernet" source=dhcp
netsh interface ip set dns name="Ethernet" source=dhcp

Swap Ethernet for Wi-Fi or whatever the adapter is named in ipconfig.

Step 3: Hunt for ghost adapters

This is where most people give up too early. Windows keeps hidden network adapters around after you uninstall a VPN or Hyper-V vSwitch. Those ghosts hold onto IP addresses, and when a new adapter tries to claim one, NDIS spits out the invalid address error.

Open Device Manager, click View → Show hidden devices, expand Network adapters. Anything greyed out is a ghost. Right-click and uninstall it. Then, in an admin prompt:

set devmgr_show_nonpresent_devices=1

Reboot again. You should see the error stop appearing in Event Viewer under the Microsoft-Windows-NDIS provider.

Why the error happens at all

What's actually happening here is that a driver or application called NdisOpenAdapterEx or a socket-level bind() with an address that NDIS can't resolve to a live miniport. NDIS sits between the network protocol stack (TCP/IP) and the physical/virtual miniport drivers (your NIC, Wi-Fi card, Hyper-V vSwitch, WAN Miniport). When it gets a request for an address that isn't bound to any miniport it can see, it returns NDIS_STATUS_INVALID_ADDRESS, which surfaces as 0x80340022.

Step 1 works because it wipes the LSP chain that's been mangling addresses. Step 2 works because it removes the stale address that no live interface can claim. Step 3 works because hidden miniports still register with NDIS even though they aren't plugged into anything — and NDIS happily tries to route the bind to them, then fails when the address doesn't match.

Less common variations

Hyper-V vSwitch stuck on an invalid address

If you're on Windows 10/11 Pro with Hyper-V enabled and the error appeared right after you created an External vSwitch, the vSwitch may have grabbed an IP that conflicts with the host. Delete the vSwitch in Hyper-V Manager, reboot, recreate it. Don't try to fix it from the Network Connections panel — you'll just break the host adapter too.

VPN client leftovers

Cisco AnyConnect, older OpenVPN TAP drivers, and some corporate Zscaler builds install miniports that hang around after uninstall. Check HKLM\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318} for adapter entries whose DriverDesc references a VPN you removed. Remove the matching subkey, then reboot.

IPv6 binding failures on loopback

Some older apps try to bind to ::1 when only IPv4 is enabled on the adapter. Disable IPv6 in adapter properties and the app's bind will fall back to 127.0.0.1 cleanly. The proper fix is updating the app, but disabling IPv6 is the practical workaround.

Prevention

Don't set static IPs on laptops you travel with. Use DHCP reservations on the router instead — same effect, no broken configs when you change networks.
Before uninstalling a VPN client, disconnect it and disable its adapter in Network Connections first. Then uninstall. This avoids the ghost miniport problem entirely.
When you tear down a Hyper-V vSwitch, do it through Hyper-V Manager, not Device Manager. Hyper-V cleans up its own NDIS registrations; Device Manager doesn't.
Run netsh winsock reset after any antivirus upgrade that touches network filtering. It takes 30 seconds and saves you an hour of Event Viewer archaeology later.

If the error persists after all three steps and a reboot, capture a trace with netsh trace start scenario=NetConnection capture=yes, reproduce the failure, then netsh trace stop. The resulting .etl file will show which miniport NDIS is trying to reach. That's the one to uninstall next.