Current progress:

• We have been unable to reproduce this issue locally with the same hardware. The remaining differences between our test setup and the user's are the Windows version (we tested on Windows 11 and Windows 10 22H2) and the test program (ours being a modified version of pcap_filter.exe that may perform other actions on the capture handle that may interfere).
• We have a crash dump manually generated by the user at the point when the connection is interrupted. We hope to identify inconsistencies with the state of the driver and the stack at this point to indicate the cause of the problem.
• The user has provided a copy of the VM where the issue presents. We hope to use this to reproduce locally where we can use a live debugger.

The manual memory dump revealed that the miniport packet filter was unset, meaning that no packets were being delivered up the stack. When we changed our test program to avoid setting promiscuous mode (which is done via hardware packet filter), we were able to reproduce the issue. Using a debug build and DbgView, we saw that the protocol drivers were sending OID_GEN_CURRENT_PACKET_FILTER Set requests while our filter module was in a Paused state, and that Npcap was not propagating these requests because its internal state assumed that the effective filter had already been set (not knowing it had been reset during the pause/detach/attach sequence). As a result, the hardware filter was never set, and the miniport would not deliver any packets.

The fix to this issue was to remove the code that attempted to short-circuit such OID requests on the assumption that they were redundant. Instead, all such requests will be propagated. The change is in e9e59b8.