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...

I filed MicrosoftDocs/windows-driver-docs#3456 against the Microsoft documentation; the documentation on porting miniport drivers to NetAdapterCx might not be making it clear enough that the ported driver should call NetAdapterSetReceiveFilterCapabilities() to set the bitset of supported packet filter capabilities. If that's not being done by a NetAdapterCx driver, that might cause the Npcap driver to send a packet filter with some bits that need to be set not being set and, if either the NetAdapterCx code or the miniport driver responds to that with an error that maps to NDIS_STATUS_FAILURE/STATUS_UNSUCCESSFUL, that could produce these symptoms.

Oh, look, the NetAdapterCx code is open source!

NetAdapterSetReceiveFilterCapabilities() just passes the NET_ADAPTER_RECEIVE_FILTER_CAPABILITIES * on to nxAdapter->SetReceiveFilterCapabilities(*ReceiveFilter);.

The SetReceiveFilterCapabilities method of an NxAdapter instance just copies the structure to the m_receiveFilterCapabilities element of the instance.

The SetReceiveFilter method of an NxAdapter instance will...

...return STATUS_NOT_SUPPORTED if the m_receiveFilterCapabilities element of the instance is 0.

I'm not seeing any obvious way where NDIS_STATUS_FAILURE/STATUS_UNSUCCESSFUL would be returned by the NetAdapterCx code for an attempt to set the packet filter; furthermore, the driver routine that's called by the SetReceiveFilter method has no return value (void), so it can't report a failure.

So either something in NDIS is returning NDIS_STATUS_FAILURE/STATUS_UNSUCCESSFUL or the failure is happening in some other code path.

I can run some debug build with both driver types, I you'd like to trace something.

So either something in NDIS is returning NDIS_STATUS_FAILURE/STATUS_UNSUCCESSFUL or the failure is happening in
some other code path.

If someone had just tried to compile using gcc -Wall and/or clang-cl -Wall, he'd notice there are many warnings like
warning: variable 'plen' may be uninitialized when used here.

I cooked up this GNU makefile to try to use clang-cl to build NPF.sys. It worked, but I've not tried to use it for real.
Be warned, using clang-cl -Wall with the Windows-DDK is a very noisy experience.
BTW. the code doesn't even compile without these:

• -DHAVE_DOT11_SUPPORT
• -DHAVE_WFP_LOOPBACK_SUPPORT
• -DHAVE_RX_SUPPORT.

So what's the purpose of these?

So either something in NDIS is returning NDIS_STATUS_FAILURE/STATUS_UNSUCCESSFUL or the failure is happening in
some other code path.

If someone had just tried to compile using gcc -Wall and/or clang-cl -Wall, he'd notice there are many warnings like warning: variable 'plen' may be uninitialized when used here.

There's no variable named plan in either Openclos.c or Packet.c, which is where this particular code path exists. However, either or both of those files may produce warnings when compile with gcc/clang and -Wall; it might be worth looking into whether the MSVC warning level could be cranked up here as well.

There's no variable named plan

plen.

There's no variable named plan

plen.

Damn you, autocorrect. What I checked for in the Npcap source was plen, not plan.

Same Problem with npcap 1.73.

I ordered a USB Ethernet adapter that uses the Realtek drivers, and after updating the driver from the Realtek website, I was able to reproduce the issue. I used the debug build of the Npcap driver and the DebugView application from MS Sysinternals to get a log of what is happening. Here is the relevant section:

NPF_IoControl: ENTER
NPF_IoControl: Function code is 0021a820 Input size=0000000f Output size 0000000ffuncBIOC_OID: BIOCSETOID Request: Oid=0001010e, Length=00000004
NPF_StartUsingOpenInstance: OpenStatus = 2; MaxState = 2
NPF_SetPacketFilter: pFiltMod=FFFFC00B179CF5D0, PacketFilter=0x20
NPF_SetPacketFilter: New packet filter: 0x2b
NPF_DoInternalRequest: ENTER
NPF_Status: status 40010024
NPF_OidRequestComplete: ENTER
NPF_OidRequestComplete: pFiltMod(FFFFC00B179CF5D0) INTERNAL_REQUEST Oid 0x1010e, Status 0
NPF_OidRequestComplete: EXIT
NPF_DoInternalRequest: pFiltMod(FFFFC00B179CF5D0) OID SET 0x1010e: Status = 0
NPF_DoInternalRequest: EXIT
NPF_SetPacketFilter: BytesProcessed != sizeof(PacketFilter), BytesProcessed = 0, sizeof(PacketFilter) = 0x4
NPF_SetPacketFilter: EXIT
funcBIOC_OID: Original NdisFOidRequest() Status = 0xc0000001
funcBIOC_OID: Custom NdisFOidRequest() Status = 0xe0000001
NPF_IoControl: Status = 0xe0000001
NPF_IoControl: EXIT

The same BytesProcessed != sizeof(PacketFilter) issue happens when setting any packet filter, regardless of promiscuous mode or not. Since this is a violation of the NDIS specification (a driver must set the NDIS_OID_REQUEST.DATA.SET_INFORMATION.BytesRead to the number of bytes read for a set operation), this can be viewed as a bug in the Realtek driver. However, Npcap should probably not be so picky when it comes to requiring this, especially since so many people are being prevented from using it because of this. So I will change NPF_SetPacketFilter() and several other similar functions to not require this in the case of NDIS_STATUS_SUCCESS.

Awesome work, @dmiller-nmap!

this can be viewed as a bug in the Realtek driver

Or, if that driver is a NetAdapterCx driver, possibly in the NetAdapterCx code. (I may take a deep dive later, but it's a bit of a case of a twisty little maze of code paths.)

But, in either case, it's in code we're forced to deal with, so, yes, we need to stop caring whether the code does the right thing or not.

@guyharris I think you're right. It doesn't seem like a NetAdapterCx client driver knows anything about NDIS_OID_REQUEST structures, so it should be a change to MS's code that is needed.

My initial comment is that Npcap 1.74 works with Wireshark 4.0.5 on Windows 11.

Thanks!

https://npcap.com/#download

Yes I can also confirm, with 1.74 it's working again.

Thanks!

Working on Intel I225 / I226 LAN Driver V2.1.3.3 NetAdapterCx driver.
Thank for your effort and great job!

Yep, also working on Realtek "RTL8111/8168 PCI Express Gigabit Ethernet controller" driver v1.0.0.14.
Many thanks!

Installing last version of Npcap resolved problem.
Confirm work with my "Realtek PCIe 2.5GbE Family Controller" (Default Microsoft driver 1.0.0.14 at 01.02.2021)
Many thanks

1. Microsoft Windows [Version 10.0.22621.1778]
2. Name DisplayName ComponentID Enabled

Realtek Npcap Packet Driver (NPCAP) (Wi-Fi) INSECURE_NPCAP_WIFI True
TPLink Npcap Packet Driver (NPCAP) (Wi-Fi) INSECURE_NPCAP_WIFI True
3. Problem was only with Realtek Ethernet adapter, WiFi works fine.
Driver is (from DUMo)
Realtek PCIe GbE Family Controller Realtek 1168.12.320.2023 Update available (1168.13.424.2023)

npcap was 1.71

Upgrade npcap to 1.75 resolves problem. Thanks all.

I have the same issue and actually i don't know how to solve it...I need wireshark for a debug at work... without it i don't know how to do that, ok little edit, i solved it giving wireshark admin's powers

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.

Oh man thanks a lot, the problem was fixed!!!! It's time to filter my network traffic!!!!!! A big hug from Spain, bro

It's time to filter my network traffic!!!!!!

The filter referred to here is not the same as the "capture filter", to use the Wireshark term; it doesn't do fine-grained filtering such as "tcp end not host random.machine.example.com", it just specifies what broad categories of link-layer packets are received. It's mainly used to turn promiscuous mode on or off.

The "capture filter" filtering mechanism works with or without this bug fix (assuming this bug doesn't prevent you from capturing at all).

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.

Oh man thanks a lot, the problem was fixed!!!! It's time to filter my network traffic!!!!!! A big hug from Spain, bro

the issue is fixed already, no need to downgrade, you just have to upgrade to the latest version because it's not included in the Wireshark installer yet

npcap 1.78 is now proposed by Wireshark 4.2.0

I'm seeing issue here in Jan 2024 with latest Win11 Home build (10.0.22621 Build 22621), and USB serial stopped being recognized in Wireshark (Silicon Labs CP210X). the port works fine even to 1M BAUD to transfer data, just wireshark cannot use it. was working fine last year. also have a brand new laptop, with new install, same windows, same issue.
Tried 1.6, 1.74, 1.78 NPCap. using USBPcap 1.5.4.0
I have a Renesas 3.4.7 special version of Wireshark.

I'm seeing issue here in Jan 2024 with latest Win11 Home build (10.0.22621 Build 22621), and USB serial stopped being recognized in Wireshark (Silicon Labs CP210X). the port works fine even to 1M BAUD to transfer data, just wireshark cannot use it.

If your issue does not involve an error message that says that a program "failed to set hardware filter to promiscuous mode", then it is not the same issue, and you should not add your issue as a comment in this issue, you should file a separate issue.

Libpcap/Npcap do not support serial ports as devices on which to capture traffic. Wireshark might have an "extcap" program that supports it, but those are not part of libpcap or Npcap, so a problem with an "extcap" is not a problem with libpcap or Npcap.

using USBPcap 1.5.4.0

USBPcap is an "extcap", and is capable of capturing raw USB transactions. If it's working, it should show traffic between the host and a USB device such as your USB serial port, but it won't show it as serial-port traffic, it will show it as USB bus transactions, as that's what it's designed and intended to do

A huge shout out to @guyharris @dmiller-nmap for your tireless efforts in resolving this issue!
You guys are champions. THANK YOU!

Upgraded from:

• Wireshark version 4.0.6 (v4.0.6-0-gac2f5a01286a)
• Npcap version 1.71
  to:
• Wireshark version 4.2.4 (v4.2.4-0-g1fe5bce8d665)
• Npcap version 1.78
  on:
• 64-bit Windows 11 Home (21H2), build 22000 [Version 10.0.22000.2538], with
• Realtek USB GbE Family Controller [RTL8153]
• Realtek Driver 1153.13.20.420 (27/07/2023)

FIXED :)