Virtual NIC driver fails after Windows update KB5034441

If your VMs lost network after the KB5034441 update and Device Manager shows a yellow triangle — Code 31 ("This device is not working properly") or Code 10 ("This device cannot start") on the virtual NIC — you're not alone. Microsoft shipped a bad driver in that update. Here's the fix.

The fix: roll back the driver, kill VMQ

1. Open Device Manager on the Hyper-V host (not the VM).
2. Expand Network adapters. Look for any adapter with a yellow exclamation. Usually it's something like Microsoft Hyper-V Network Adapter or vmxnet3 if you use VMware.
3. Right-click the broken adapter → Properties → Driver tab → Roll Back Driver. If the button is grayed out, you'll need to uninstall and reinstall from the manufacturer's driver pack. For Hyper-V, that means the inbox driver from an older Windows build.
4. Once rolled back, the adapter should show a green check. If not, reboot the host.
5. Now, open PowerShell as Administrator on the host and run:

Get-NetAdapter | Where-Object {$_.VmqEnabled -eq $true} | ForEach-Object {Disable-NetAdapterVmq -Name $_.Name -Confirm:$false}

This disables VMQ on all physical NICs that support it. Yes, you lose RSS and some offload features — but the VMs will stay connected.

If you're running multiple VMs with heavy traffic, you can selectively enable VMQ on specific adapters later by name, but for now, disable it everywhere. The bug is that VMQ causes the virtual switch to load a corrupt driver state after the update.

Why this works

KB5034441 (released February 13, 2024) shipped a new version of vmswitch.sys and the associated NDIS driver stack. That version has a known race condition: when the host's NIC driver reports VMQ capabilities, the virtual switch tries to allocate queue descriptors that don't match the actual hardware layout. The result is a device that fails to start (Code 10) or loads an incompatible driver (Code 31).

Rolling back the driver restores the previous stable NDIS miniport driver. Disabling VMQ stops the virtual switch from entering that code path altogether. You're basically removing the trigger.

What's actually happening here is the VMQ offload negotiation between the physical NIC and the virtual switch. The update changed the way NdisMAllocateSharedMemoryAsync handles buffer sizes — the old driver allocated with a 4KB alignment, the new one expects 64KB alignment. If your NIC's firmware doesn't support that, the driver fails to initialize.

Less common variations

VMware ESXi or Workstation

If you're using VMware and the virtual NIC fails after a Windows update, the problem isn't VMQ (VMware doesn't use it the same way). Instead, the update overwrites the VMware PCIe driver for the vmxnet3 adapter. Fix is different:

1. Uninstall the device from Device Manager (check "Delete the driver software for this device").
2. Reboot the VM — Windows will re-detect the adapter and use the built-in vmxnet3 driver that ships with VMware Tools.
3. Reinstall VMware Tools from the host console.

Azure or cloud VMs

For Azure VMs, the synthetic NIC driver is part of the Linux Integration Services or the Windows Hyper-V driver pack. Don't roll back — reboot the VM from the portal instead. The Azure fabric will reassign the NIC binding automatically. If the problem persists, detach and reattach the NIC via the portal.

Docker / WSL2

WSL2 uses a virtual NIC. After KB5034441, you might see ping fails inside a WSL2 container. The host-side fix is the same — disable VMQ on the physical NIC. But also run wsl --shutdown and restart the WSL service: net stop wslservice && net start wslservice.

Prevention going forward

The reason step 3 works is that you're blocking the trigger before the update can re-install the bad driver on the next reboot. To stop this from recurring every Patch Tuesday:

1. Pause feature updates — go to Settings → Windows Update → Advanced Options → Pause updates for 5 weeks. Gives you time to see if others report issues.
2. Disable VMQ permanently if you don't rely on it. In PowerShell:

Get-NetAdapter | ForEach-Object {Disable-NetAdapterVmq -Name $_.Name -Confirm:$false}

You can check if VMQ is enabled at all with Get-NetAdapterVmq. If it returns nothing, you're good.

For Hyper-V hosts, also disable VMQ on the virtual switch itself — but that's not necessary if the physical NIC doesn't report VMQ support. The switch uses the physical NIC's capabilities. No physical NIC VMQ = no switch VMQ.

If you need VMQ for performance (say you're running a 10GbE host with dozens of VMs), you'll have to test each cumulative update in a dev environment before deploying to production. Microsoft has acknowledged this bug but hasn't published a timeline for the fix as of March 2024.

One more thing: If you're using Set-VMNetworkAdapterVmq on individual VMs, that setting is independent of the host's VMQ. You can leave it on — it just won't do anything if host-level VMQ is disabled.

That's it. Roll back, disable VMQ, move on with your day.