Bluescreen on Windows 8.1

[Johann999]

Bluescreen (ndis.sys) on Windows 8.1 with npcap 1,60

[dmiller-nmap]

Thanks for reporting this. Can you please provide some additional information as described in the Npcap User's Guide? The most useful information to debug this would be the kernel minidump from C:\Windows\Minidump\ that corresponds to this crash. If you would rather use email, please send to dmiller@nmap.com.

[Wildcat97]

I appear to be having the same issue with npcap 1.60 on Windows 8.1. The machine becomes unstable very quickly after installing. And when I restart the PC all I have to do is wait about 3 minutes, and I'll get the BSOD with the error regarding NDIS.SYS. I don't have to start any applications. I had a very difficult time running DiagReport as the PC would blue screen when the utility was running.

I've uninstalled 1.60 for now, and now back to running 1.55. Everything is fine.
DiagReport-20211230-051019.txt

[cyril-orlov]

Hi, have the same issue. Fails in ndisCreateStringStreamEntry. I've sent a minidump to you. I have 2 other NDIS filters running for years with no issues (VirtualBox and Comodo) but I've disabled them in my adapter (had to do it anyway because Wireshark would not show the adapter and nmap would show WINDEVICE NONE).
Reinstalled 1.60 without "Raw 802.11 Packet Capture Support", looking ok so far but too early to tell.

[ntoskrnl11]

I have the same issue. Npcap 1.60 and Windows Server 2012 R2. I will send you a minidump. Oddly, this problem only started approximately 1 day after initial installation.

Without Driver Verifier: The machine will bluescreen within a few minutes after rebooting with a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED error with a reference to ndis.sys.
With Driver Verifier: The machine will bluescreen within a few seconds after rebooting with a SYSTEM_THREAD_EXCEPTION_NOT_HANDLED error with no reference to any driver.

I can confirm that "Raw 802.11 Packet Capture Support" seems to be the problem, as everything seems to work fine after I reinstalled without that option.

[dmiller-nmap]

Since Npcap is not in the call stack of the crash, it's nearly impossible to know what part of Npcap might be related. We made significant improvements and changes to the driver in Npcap 1.70 that may have addressed the issue. Can anyone confirm whether Npcap 1.70 fixes the problem?

[Wildcat97]

I can't as I have upgraded my operating system to Windows 10 since I reported what I ran into. Npcap 1.60 works fine in Windows 10.

[binarymaster]

Can anyone confirm whether Npcap 1.70 fixes the problem?

The problem still happens with Npcap 1.70 and Windows 8.1 host. Here are some details on it:

• BSOD happens right after 6 minutes since boot up
• It happens even if all network interfaces are disabled (except loopback, as you cannot simply disable it)
• Happens even if no user is logged in system

My system specs:

• Lenovo ThinkPad x240
• Windows 8.1 Pro x64 (Version 6.3 build 9600)
• Npcap was installed with these options: 802.11 raw packets enabled, WinPcap compatibility enabled

Crash minidump attached: minidump.zip

• BugCheck code: SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
• Exception code: c0000005 (Access violation)
• Faulting instruction: ndis!ndisCreateStringStreamEntry+2f

[dmiller-nmap]

Thanks for the crash dumps. Unfortunately, we still cannot determine how or if Npcap is involved in these crashes. A complete memory dump (C:\Windows\MEMORY.DMP) would be helpful. In the meantime, here is the information we have gathered from these minidumps:

Crash stack:

 # Child-SP          RetAddr               Call Site
00 ffffd000`22ec64c0 fffff800`2d131689     ndis!ndisCreateStringStreamEntry+0x2f
01 ffffd000`22ec64f0 fffff800`2d0aca70     ndis!ndisSqmLogDriverVersion+0xb9
02 ffffd000`22ec68d0 fffff802`258f528f     ndis!ndisSqmTimerWorkerRoutine+0x150
03 ffffd000`22ec6b50 fffff802`25983a34     nt!ExpWorkerThread+0x69f
04 ffffd000`22ec6c00 fffff802`259eb5d6     nt!PspSystemThreadStartup+0x178
05 ffffd000`22ec6c60 00000000`00000000     nt!KiStartSystemThread+0x16

3rd-party drivers in common:

• npcap
• vbaudio_cable64_win7
• VBoxNetLWF and VBoxUSBMon

[dmiller-nmap]

@jtippet any clues as to what NDIS is doing in that call stack? Is there any way Npcap (a modifying LWF, but also a LWF in the undocumented ms_medium_converter_128 FilterClass) could be doing something wrong that would end up with a crash in this location on Win8.1? Thanks for any ideas you might have.

[jtippet]

From what I can see in the minidump, NDIS is tripping over a bogus filter driver record named npcap_wifi. My hunch is that npcap is leaking its NdisFRegisterFilterDriver in the DriverEntry failure path.

There's maybe a little gotcha from the asymmetry of the rules here:

• for WDF-based drivers, you don't have to clean up much of anything allocated from WDF; WDF usually cleans it up for you, even in failure cases
• for PNP-based drivers, you don't have to clean up your driver object if DriverEntry fails; PNP handles that for you. In particular, you don't have to call NdisMDeregisterMiniportDriver if your DriverEntry fails.
• for NDIS LWFs, you must always call NdisFDeregisterFilterDriver after each successful call to NdisFRegisterFilterDriver -- regardless of what you return from DriverEntry. (A similar thing is true for protocols and NdisDeregisterProtocolDriver).

That third bullet might come as a bit of a surprise if you're accustomed to the miniport world (bullet #2).

So, concretely, audit your DriverEntry and ensure that, if NdisFRegisterFilterDriver succeeds:

• you return STATUS_SUCCESS from your DriverEntry; or
• you call NdisFDeregisterFilterDriver before returning a failure status from DriverEntry.

If you call NdisFRegisterFilterDriver multiple times, then you need to have a corresponding NdisFDeregisterFilterDriver for each successful registration.

And, for the record, note that from the moment you call NdisFRegisterFilterDriver, NDIS is allowed to call into your FilterAttach handler at any time. NDIS can keep calling into your FilterXxx handlers right up until NdisFDeregisterFilterDriver returns. So there's usually a right place to insert NdisFDeregisterFilterDriver -- if you deregister too late after you've already destroyed your other internal state (your internal locks, memory allocations, whatever), then you're racing against a FilterAttach. A good rule of thumb is to initialize nearly everything first, then register with NDIS; and for the cleanup path, do it all in reverse order.

[dmiller-nmap]

@jtippet Thanks so much for the insight! We definitely have run into the early FilterAttach issue before, as evidenced by this line in DriverEntry:

npcap/packetWin7/npf/npf/Packet.c

Lines 458 to 459 in f63c334

	/* Have to set this up before NdisFRegisterFilterDriver, since we can get Attach calls immediately after that! */
	NdisAllocateSpinLock(&g_FilterArrayLock);

[dmiller-nmap]

@jtippet I believe I have figured out what is going on. We made a change a while back (4bbdb85) to use the "null service" in our INF for the secondary functions of Npcap (this LWF for raw WiFi frame capture and the WFP callout driver for loopback traffic capture). The intent was to avoid having a "disabled service" installed in the Registry, since all functions (both LWFs and the WFP, plus the WDM driver that provides the interface with user software) run from a single binary, npcap.sys, with a single DriverEntry function that initiates all functions. However, I see in the disassembly that the read instruction is cmp, and the address read from is in r9, 8 bytes past the address in rdx.

fffff800`3076756b 4c8b4a08        mov     r9,qword ptr [rdx+8]
fffff800`3076756f 66413929        cmp     word ptr [r9],bp ds:002b:00000000`00000000=????

Looking in the memory, I see that qword is the 8 bytes immediately before the FriendlyName for this LWF, so I attached a debugger to a good running system and looked for the FriendlyName within the memory block address for our primary LWF from !ndiskd.filterdriver, and the same offset has a valid address in it. It's allocated from "Pooltag NDan : adapter name, Binary : ndis.sys" and points to the UNICODE_STRING "npcap.sys". This leads me to believe that using the "NULL driver" AddService directive in the INF is the cause of this crash, which is actually a null pointer dereference in ndis.sys.

It should not be a problem to back out our change for the next release, which should resolve the issue.

[dmiller-nmap]

Here's the original StackOverflow answer explaining how the AddService lines are supposed to work and why: https://stackoverflow.com/a/39170937/1183387

[fyodor]

We believe this is resolved with Npcap 1.71 since @dmiller-nmap backed out the INF change as described above. So I'm closing this, but folks can still comment if for some reason you're still seeing the issue with 1.71.