NDIS Virtual Network Adapter Enumerator in Windows 11: Fix Code 22 or 52

What NDIS Virtual Network Adapter Enumerator is—and what the name does not prove

Windows inventories identify this Microsoft system device as NdisVirtualBus, commonly with the instance ID ROOT\NdisVirtualBus\0000 and Microsoft INF ndisvirtualbus.inf. Microsoft documentation also describes NDIS as supporting enumeration of network miniport adapters and virtual connections.

That does not make this entry a physical Wi-Fi or Ethernet adapter, and its presence does not by itself prove Hyper-V is active, malware is installed, or your network is broken. Diagnose the status code and the actual network symptom separately.

Fix path #1 — Code 22: enable the device

Microsoft defines Device Manager Code 22 as “This device is disabled.” Its recommended resolution is to enable the device. If you did not intentionally disable NDIS Virtual Network Adapter Enumerator, use Enable device rather than uninstalling system components.

Verify: Reopen Properties → Device status. Code 22 should be gone. Then test the network function that was actually failing. Do not claim success merely because the warning icon disappeared if your original network symptom remains.

Fix path #2 — Code 52: treat it as a signature/driver problem

Microsoft defines Code 52 as Windows being unable to verify the digital signature for the driver required by the device. Microsoft lists an unsigned or corrupted driver as possible causes and recommends obtaining a current properly signed driver rather than bypassing signature enforcement.

For this Microsoft system-device entry, first record your Windows edition/build and whether Code 52 appeared after an update, rollback, image modification, driver package, security-policy change or other system change. Treat timing as evidence—not proof. Before repair, capture Driver Provider, Driver Date, Driver Version and the driver/INF identity shown by the device's Driver Details/driver information. Then compare scope: is Code 52 limited to NdisVirtualBus, or do other unrelated devices also show signature-verification failures?

If only this device is affected, keep the investigation on its bound package/component before resetting the whole networking stack. If multiple unrelated devices show Code 52, the evidence shifts toward a broader Windows driver-signing/trust/component-integrity problem. Use Windows Update and the supported Windows/OEM repair path appropriate to that scope rather than bypassing signature enforcement.

Verify: After a scope-appropriate supported update/repair and restart, confirm the same device instance no longer reports Code 52 and test the original network symptom. If the warning changes to another Device Manager code, stop diagnosing Code 52 and follow the new code. If Code 52 remains, stop repeating driver toggles and preserve the bound driver/INF and scope evidence.

If you see a different Device Manager code

Code 22 and Code 52 are not interchangeable with Code 31, 32, 43, or other Device Manager statuses. Microsoft assigns different causes and resolutions to different codes. Use the exact code shown in Device status as the next diagnostic key.

Verify: Record the full message—not just the yellow warning icon—before applying another fix.

If networking is broken but the enumerator has no error

Do not make this system-device entry the root cause merely because its name contains “Network Adapter.” Check the adapter or feature that actually fails: Wi-Fi/Ethernet connection state, the relevant virtual adapter, VPN software, or the application using the network. A normal NDIS Virtual Network Adapter Enumerator status is evidence to move the investigation elsewhere.

Verify: Tie every repair to the original symptom. Do not reset Winsock, TCP/IP, every adapter or all network settings merely because NdisVirtualBus is visible in Device Manager.

Still not fixed? Capture this evidence

References