npcap
npcap copied to clipboard
failed to set hardware filter to promiscuous mode with Windows 11
Describe the bug After Upgrade from Windows 10 to Windows 11 I can't capture any more in promiscuous mode. I tried it with my LAN Interface not WLAN. I upgraded npcap from 1.70 to 1.71 and tried Wireshark 3.6.7, 3.6.8 and 4.0.0rc1
Message is: The capture session could not be initiated on capture device "\Device\NPF_{8B94FF32-335D-443C-8A80-F51BDC825F9F}" (failed to set hardware filter to promiscuous mode: Ein an das System angeschlossenes Gerät funktioniert nicht. (31)).
To Reproduce Steps to reproduce the behavior:
- Doubleclick on the Interface from StartScreen
- Otherwise go to Capture Options.
- Than check the promiscous mode
- last click on start.
Expected behavior A working capture. ;-)
Screenshots

Diagnostic information
- Windows version from
winver: Windows 11 Version 21H2, OS Build 22000.856 - Output of DiagReport-20220908-131205.txt
- install.log
The Problem only occurs with LAN adapters. At virtualbox, WLAN, WWAN promiscuous mode can be enabled at capture start.
USB LAN nor docking is working.
31 is ERROR_GEN_FAILURE. NT status codes that translate to ERROR_GEN_FAILURE include a bunch of "somebody wrote to executable memory" codes, STATUS_WIM_NOT_BOOTABLE, and STATUS_UNSUCCESSFUL, which is, I guess, the NT status equivalent of ERROR_GEN_FAILURE, as in "something bad happened but I'm not going to tell you what it was".
There appear to be a lot of places in the driver that return STATUS_UNSUCCESSFUL.
Okay Error found: Installing the Driver for Windows 10 instead of them for Windows 11 and it works again. I don't know if it's a driver or npcap error.
Drivers are for Realtek USB devices: https://www.realtek.com/en/component/zoo/category/network-interface-controllers-10-100-1000m-gigabit-ethernet-usb-3-0-software
Can confirm I see the same issue with a Dell WD19DC dock which contains a Realtek RTL8153 USB GbE controller. Was working fine prior to Windows 11 upgrade from Windows 10 21H2. Current driver is rtu53cx22x64.sys v1153.8.20.608 (Date: 9/06/2022),
Happy to provide whatever further information would be of assistance but unsure what's most helpful.
EDIT: Using Wireshark v3.6.8 with npcap v1.71.
Just a thought: could it be related to a lack of support for the new NetAdapterCx driver model?
I have no idea if Npcap is expected to "Just Work" with NetAdapterCx drivers or if additional work is required.
The latest Windows 11 driver for the RTL8153 has the following details:
- Driver:
rtu53cx22x64.sys - Version: 1153.8.20.608
- Date: 9/06/2022
- Type: NetAdapterCx
- NDIS Version: 6.85
The latest Windows 10 driver for the RTL8153 has the following details:
- Driver:
rtump64x64.sys - Version: 10.52.20.608
- Date: 8/06/2022
- Type: NDIS miniport
- NDIS Version: 6.40
The Windows 10 driver works fine with Wireshark while the Windows 11 driver has the described error on starting capture.
Exactly same situation here. Using Intel I225-V wired adapter, Windows 11, and Wireshark 4.0.0.
Downgrading to NDIS68 (v1.1.3.28) solves this issue for me.
On Windows 11, get the same message with Wireshark 4.0.0 and npcap 1.71 (but not with npcap 1.60) on the Ethernet interface (with the Wi-Fi, it was fine).
I reported the issue on Wireshark Q&A : https://ask.wireshark.org/question/29016/cannot-initiate-capture-session-on-a-device-after-having-installed-400/
My workaround after installing Wireshark 4.0.0 was to downgrade npcap to 1.60. This means some regression has been introduced in 1.71. Device manager shows Realtek PCIe GbE Family controller, date 2021-01-27, version 1.0.0.4.
Same. Error introduced after upgrade to 1.71; resolved by downgrading back to 1.60. Using Killer E3100 2.5 Gbps interface.
I, too, was able to resolve my error (Windows 11 / Wireshark 4.0.1) by downgrading npcap from 1.71 to 1.60. Thanks for the info!
A colleague of mine (who does not have a GitHub account) has a similar issue, however, for him it happens on Windows 10. He is using a "QLogic BCM57810" network card, I don't know what chipset this card contains. Downgrading to npcap 1.60 fixed his issue as well. The driver is quite old as QLogic themselves have been bought up multiple times and their successor companies more less seem to have stopped support.
This happens on Windows 10, Aquantia AQtion AQC107 10Gbit Network Adapter. Downgrade to npcap 1.60 fixed it.
Previously worked on 1.60 but got the same error as yours on 1.71. Realtek Gaming 2.5GbeE Family Controller.
Same here, previously worked on 1.60 but not 1.71, Realtek Gaming GbE Family Controller on laptop and Realtek USB GbE Family Controller on PC. Windows 11 x64 22H2 22621.755
downgrade to 1.6 not always work,still got the problem.
I'm getting the same issue in Xemu (QEMU based Xbox Emulator) with an Intel(R) Ethernet Controller I225-V
Exactly the same problem here with a Tripp-Lite, a TP-Link and a Belkin USB adapter. They identify themselves as:
->TP-LINK Gigabit Ethernet USB Adapter ->Realtek USB GbE Family Controller ->Realtek USB GbE Family Controller
Downgraded to NPACP 1.60 and everything works fine.
Question: Are there any USB Network adapters that works with version 1.71 on Win11 at all?
FWIW Npcap 1.72 did not fix this problem yet (Windows 11 22H2, Wireshark 4.0.2):

Npcap 1.60 still works.
@markkuleinio I installed Wireshark 4.0.2 a few hours ago and it came with npcap 1.71. Thanks for letting me know I should skip 1.72 as well! Hopefully this gets resolved sooner. Reverting the changes might be a good idea until a solution is found.
If there's an Npcap developer watching this, I'd be quite happy to provide the output from a debug build if one can be provided to help track down the root cause.
I encountered the same issue on Windows 11 22H2, 22621.963.
The network adapter is identified as Lenovo USB Ethernet, VID_17EF&PID_720C.
Downgrading to 1.60 indeed works.
The same issue
Same here... After installing 1.60 it works...
@jtippet Somebody asks, in this comment, "could it be related to a lack of support for the new NetAdapterCx driver model?"
I haven't found anything at learn.microsoft.com that looks like reference documentation for NetAdapterCx - some tutorial information, but nothing giving raw API details, siuch as, for example, how a NetAdapterCx driver is notified that an OID get or set operation is performed. What happens if you do an OID_GEN_CURRENT_PACKET_FILTER set operation? Is a NetAdapterCx driver told that the filter has changed, and what the new filter is?
So, based on the GUID in the bug text and the error dialog, and the DiagReport, from the original bug report, the two adapter with the problem is "Lenovo USB Ethernet", with a manufacturer of Realtek and a service name of rtu53cx22x64, on Windows 11.
Other adapters reported are:
- Realtek RTL8153 USB GbE controller, with the same driver, rtu53cx22x64.sys, Windows 11.
- Intel I225-V, Windows 11.
- Realtek PCIe GbE Family controller, unknown Windows version.
- Intel Killer E3100, Windows 11.
- Aquantia (Marvell?) AQtion AQC107 10Gbit Network Adapter, Windows 10.
- Realtek Gaming 2.5GbeE Family Controller, unknown Windows version.
- Realtek Gaming GbE Family Controller and Realtek USB GbE Family Controller, Windows 11.
- Xemu (QEMU based Xbox Emulator) with an Intel(R) Ethernet Controller I225-V, unknown Windows version.
- TP-LINK Gigabit Ethernet USB Adapter, unknown chipset, unknown Windows version.
- Lenovo USB Ethernet, VID_17EF&PID_720C, Windows 11.
- Intel Killer E3100, e3k25cx21x64 driver, Windows 11.
So this is not a problem only with USB adapters, given that there's at least one report with a PCIe controller.
And this is not a problem only with Windows 11, given that there are some reports on Windows 10.
It might be a NetAdapterCx problem, if the driver for the adapter is, in all cases, a NetAdapterCx driver rathr than an NDIS driver.
Thanks for all of the reports! This data really helps and we'll be discussing the issue in tomorrow's engineering meeting. We've also added it to the list of issues we're planning to fix for the upcoming 1.73 release.
Is a NetAdapterCx driver told that the filter has changed, and what the new filter is?
Yes. A NetAdapterCx-based driver would advertise its supported flags by calling NetAdapterSetReceiveFilterCapabilities. When p-mode is enabled, the adapter receives an EVT_NET_ADAPTER_SET_RECEIVE_FILTER callback.
The actual netadaptercx code that handles this is available on github; you can see that it does a few checks to make sure the requested flags are supported by the driver, a bit of synchronization with other state-changing events, then sends the flags down. I'm not seeing a lot of opportunities for bugs to lurk in here, but maybe I'm overlooking something; there are a lot of customer reports, so something's clearly broken.
Seeing the same issue so here is a further data point:
Asus ROG STRIX Z690-A Gaming WiFi D4 motherboard Windows 11 with latest updates Intel wired ethernet controller I225-V Driver version 2.1.2.3 (21/09/22)
Thanks for looking into this.
Hi @Peter-Simpson , @rpersak, and @MaksymSofer, @davidebeatrici, @httpstorm, @ralish and anyone else experiencing this issue. Thanks for the reports, and can you please confirm using the Wireshark Help -> About dialogue that you are using Npcap Version 1.72? It was released on December 14 with a fix that we thought might resolve this. But if you're getting Npcap through Wireshark rather than from https://npcap.com, you might be using an older Npcap still. We'd like to hear from more people using 1.72. Thanks!
Confirmed (Npcap 1.72):
Version 4.0.2 (v4.0.2-0-g415456d13370). ... Running on 64-bit Windows (22H2), build 22621, with 12th Gen Intel(R) Core(TM) i7-1270P (with SSE4.2), with 32435 MB of physical memory, with GLib 2.72.3, with PCRE2 10.40 2022-04-14, with Qt 5.15.2, with Npcap version 1.72, based on libpcap version 1.10.2-PRE-GIT, with c-ares 1.18.1, with GnuTLS 3.6.3, with Gcrypt 1.10.1, with nghttp2 1.46.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with LC_TYPE=Finnish_Finland.utf8, binary plugins supported.
The capture session could not be initiated on capture device "\Device\NPF_{A586373D-21B0-41D4-995B-3617E49AEBCE}" (failed to set hardware filter to promiscuous mode: A device attached to the system is not functioning. (31)). Please turn off promiscuous mode for this device
The same error also with Wireshark 4.0.3 if that matters:
Version 4.0.3 (v4.0.3-0-gc552f74cdc23). ... Running on 64-bit Windows (22H2), build 22621, with 12th Gen Intel(R) Core(TM) i7-1270P (with SSE4.2), with 32435 MB of physical memory, with GLib 2.72.3, with PCRE2 10.40 2022-04-14, with Qt 5.15.2, with Npcap version 1.72, based on libpcap version 1.10.2-PRE-GIT, with c-ares 1.18.1, with GnuTLS 3.6.3, with Gcrypt 1.10.1, with nghttp2 1.46.0, with brotli 1.0.9, with LZ4 1.9.3, with Zstandard 1.5.2, without AirPcap, with light display mode, without HiDPI, with LC_TYPE=Finnish_Finland.utf8, binary plugins supported.