NdisFSendNetBufferLists causes BSoD when the adapter is being disabled

I have a NDIS 6.x LWF driver that can capture and send packets on Windows. It’s an update of WinPcap from NDIS 5 to NDIS 6.

This driver receives the packet data from the user-mode applications and send them out using NdisFSendNetBufferLists (See Line 631 in https://github.com/nmap/npcap/blob/master/packetWin7/npf/npf/Write.c). I fount out that if when the packet sending is going on, I disable the corresponding adapter in Network Connections (aka ncpa.cpl). Then the system got a blue screen. I analyzed the minidump file and the output is below:

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80745e9de30, Address of the instruction which caused the bugcheck
Arg3: ffffa38002702de0, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

Debugging Details:

*** WARNING: Unable to verify timestamp for npf.sys

DUMP_CLASS: 1

DUMP_QUALIFIER: 400

BUILD_VERSION_STRING: 14267.1000.amd64fre.rs1_release.160213-0213

SYSTEM_MANUFACTURER: Dell Inc.

SYSTEM_PRODUCT_NAME: OptiPlex 7010

SYSTEM_SKU: OptiPlex 7010

SYSTEM_VERSION: 01

BIOS_VENDOR: Dell Inc.

BIOS_VERSION: A14

BIOS_DATE: 06/10/2013

BASEBOARD_MANUFACTURER: Dell Inc.

BASEBOARD_PRODUCT: 09PR9H

BASEBOARD_VERSION: A01

DUMP_TYPE: 2

BUGCHECK_P1: c0000005

BUGCHECK_P2: fffff80745e9de30

BUGCHECK_P3: ffffa38002702de0

BUGCHECK_P4: 0

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced memory at 0x%p. The memory could not be %s.

FAULTING_IP:
ndis!NdisFSendNetBufferLists+c0
fffff807`45e9de30 4c8b5818 mov r11,qword ptr [rax+18h]

CONTEXT: ffffa38002702de0 – (.cxr 0xffffa38002702de0)
rax=6b49534e02130018 rbx=6b49534e02130019 rcx=0000000000000001
rdx=0000000000000000 rsi=ffffd50728240030 rdi=ffffd5072c4ac8d0
rip=fffff80745e9de30 rsp=ffffa380027037e0 rbp=0000000000000000
r8=0000000000000000 r9=0000000000000000 r10=0000000000000000
r11=0000000000060001 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0 nv up ei pl nz na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010206
ndis!NdisFSendNetBufferLists+0xc0:
fffff80745e9de30 4c8b5818 mov r11,qword ptr [rax+18h] ds:002b:6b49534e02130030=???
Resetting default scope

CPU_COUNT: 4

CPU_MHZ: c79

CPU_VENDOR: GenuineIntel

CPU_FAMILY: 6

CPU_MODEL: 3a

CPU_STEPPING: 9

CPU_MICROCODE: 6,3a,9,0 (F,M,S,R) SIG: 1B’00000000 (cache) 1B’00000000 (init)

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: EapolLogin.exe

CURRENT_IRQL: 0

ANALYSIS_SESSION_HOST: AKISN0W-PC

ANALYSIS_SESSION_TIME: 02-26-2016 13:42:06.0762

ANALYSIS_VERSION: 10.0.10586.567 amd64fre

LAST_CONTROL_TRANSFER: from fffff807476f67f8 to fffff80745e9de30

STACK_TEXT:
ffffa380027037e0 fffff807476f67f8 : 0000000000000000 0000000000000000 0000000000000001 ffffd5073a613570 : ndis!NdisFSendNetBufferLists+0xc0
ffffa38002703860 fffff8038c698c05 : ffffd5073a6134a0 0000000000000000 0000000000000001 fffff68000003140 : npf!NPF_Write+0x214 [j:\npcap\packetwin7\npf\npf\write.c @ 324]
ffffa380027038d0 fffff8038c69840a : ffffd50739edba60 ffffd5073a6134a0 ffffd5072871aef0 ffffa38002703b80 : nt!IopSynchronousServiceTail+0x1a5
ffffa38002703990 fffff8038c3d2f83 : ffff82081164b160 0000000000000000 0000000000000000 0000000000000000 : nt!NtWriteFile+0x67a
ffffa38002703a90 00007fff94c21034 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13
000000000014e248 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : 0x00007fff`94c21034

THREAD_SHA1_HASH_MOD_FUNC: 8de63a100febe6f9f89153a5a9abc9ba86d452de

THREAD_SHA1_HASH_MOD_FUNC_OFFSET: c12fe9b8d789ae102dec8036452ef91cdcd180b3

THREAD_SHA1_HASH_MOD: bccfea03237cfde6486a55b63bb95e3341833378

FOLLOWUP_IP:
npf!NPF_Write+214 [j:\npcap\packetwin7\npf\npf\write.c @ 324]
fffff807`476f67f8 8b6c2478 mov ebp,dword ptr [rsp+78h]

FAULT_INSTR_CODE: 78246c8b

FAULTING_SOURCE_LINE: j:\npcap\packetwin7\npf\npf\write.c

FAULTING_SOURCE_FILE: j:\npcap\packetwin7\npf\npf\write.c

FAULTING_SOURCE_LINE_NUMBER: 324

FAULTING_SOURCE_CODE:
320: NDIS_DEFAULT_PORT_NUMBER,
321: SendFlags);
322: }
323:

324: numSentPackets ++;
325: }
326: else
327: {
328: //
329: // no packets are available in the Transmit pool, wait some time. The

SYMBOL_STACK_INDEX: 1

SYMBOL_NAME: npf!NPF_Write+214

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: npf

IMAGE_NAME: npf.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 56c2d58e

STACK_COMMAND: .cxr 0xffffa38002702de0 ; kb

BUCKET_ID_FUNC_OFFSET: 214

FAILURE_BUCKET_ID: 0x3B_npf!NPF_Write

BUCKET_ID: 0x3B_npf!NPF_Write

PRIMARY_PROBLEM_CLASS: 0x3B_npf!NPF_Write

TARGET_TIME: 2016-02-26T02:30:30.000Z

OSBUILD: 14267

OSSERVICEPACK: 0

SERVICEPACK_NUMBER: 0

OS_REVISION: 0

SUITE_MASK: 272

PRODUCT_TYPE: 1

OSPLATFORM_TYPE: x64

OSNAME: Windows 10

OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS

OS_LOCALE:

USER_LCID: 0

OSBUILD_TIMESTAMP: 2016-02-13 20:56:11

BUILDDATESTAMP_STR: 160213-0213

BUILDLAB_STR: rs1_release

BUILDOSVER_STR: 10.0.14267.1000.amd64fre.rs1_release.160213-0213

ANALYSIS_SESSION_ELAPSED_TIME: 127c9

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:0x3b_npf!npf_write

FAILURE_ID_HASH: {2eb5e15e-9853-313b-618d-2ac277a2bfb5}

Followup: MachineOwner
The source code line pointed in the above dump analysis report is not very precise. It’s actually the line above numSentPackets ++;

So the below code triggers BSoD.

NdisFSendNetBufferLists(Open->AdapterHandle,
pNetBufferList,
NDIS_DEFAULT_PORT_NUMBER,
SendFlags);
It’s understandable the disable behavior of the adapter causes this BSoD, as if you have disabled an adapter, you should fail to send packets to it. I can’t stop a user disable his adapter when using my driver. But I think the only thing should happen in that condition is failing the sending action. A BSoD is too much.

So, what I want to know is what’s the correct way to let my driver prevent this according to NDIS’s design? Thanks!

I am no expert in this but is there a way to know if that AdapterHandle is
still “usable” at that stage ? Is there a way (a callback or something)
that tells you the device is in a different state so you can pend these
packets until the adapter is back up or just discard them ?

Gabriel

On Sat, Feb 27, 2016 at 3:46 PM, wrote:

> I have a NDIS 6.x LWF driver that can capture and send packets on Windows.
> It’s an update of WinPcap from NDIS 5 to NDIS 6.
>
> This driver receives the packet data from the user-mode applications and
> send them out using NdisFSendNetBufferLists (See Line 631 in
> https://github.com/nmap/npcap/blob/master/packetWin7/npf/npf/Write.c). I
> fount out that if when the packet sending is going on, I disable the
> corresponding adapter in Network Connections (aka ncpa.cpl). Then the
> system got a blue screen. I analyzed the minidump file and the output is
> below:
>
> 0: kd> !analyze -v
>
> *****
>
>
> * Bugcheck Analysis
>
>
>
>
>

>
> SYSTEM_SERVICE_EXCEPTION (3b)
> An exception happened while executing a system service routine.
> Arguments:
> Arg1: 00000000c0000005, Exception code that caused the bugcheck
> Arg2: fffff80745e9de30, Address of the instruction which caused the
> bugcheck
> Arg3: ffffa38002702de0, Address of the context record for the exception
> that caused the bugcheck
> Arg4: 0000000000000000, zero.
>
> Debugging Details:
> ------------------
>
> *** WARNING: Unable to verify timestamp for npf.sys
>
> DUMP_CLASS: 1
>
> DUMP_QUALIFIER: 400
>
> BUILD_VERSION_STRING: 14267.1000.amd64fre.rs1_release.160213-0213
>
> SYSTEM_MANUFACTURER: Dell Inc.
>
> SYSTEM_PRODUCT_NAME: OptiPlex 7010
>
> SYSTEM_SKU: OptiPlex 7010
>
> SYSTEM_VERSION: 01
>
> BIOS_VENDOR: Dell Inc.
>
> BIOS_VERSION: A14
>
> BIOS_DATE: 06/10/2013
>
> BASEBOARD_MANUFACTURER: Dell Inc.
>
> BASEBOARD_PRODUCT: 09PR9H
>
> BASEBOARD_VERSION: A01
>
> DUMP_TYPE: 2
>
> BUGCHECK_P1: c0000005
>
> BUGCHECK_P2: fffff80745e9de30
>
> BUGCHECK_P3: ffffa38002702de0
>
> BUGCHECK_P4: 0
>
> EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%p referenced
> memory at 0x%p. The memory could not be %s.
>
> FAULTING_IP:
> ndis!NdisFSendNetBufferLists+c0
> fffff80745e9de30 4c8b5818 mov r11,qword ptr [rax+18h]<br>&gt;<br>&gt; CONTEXT: ffffa38002702de0 -- (.cxr 0xffffa38002702de0)<br>&gt; rax=6b49534e02130018 rbx=6b49534e02130019 rcx=0000000000000001<br>&gt; rdx=0000000000000000 rsi=ffffd50728240030 rdi=ffffd5072c4ac8d0<br>&gt; rip=fffff80745e9de30 rsp=ffffa380027037e0 rbp=0000000000000000<br>&gt; r8=0000000000000000 r9=0000000000000000 r10=0000000000000000<br>&gt; r11=0000000000060001 r12=0000000000000000 r13=0000000000000000<br>&gt; r14=0000000000000000 r15=0000000000000000<br>&gt; iopl=0 nv up ei pl nz na po nc<br>&gt; cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b<br>&gt; efl=00010206<br>&gt; ndis!NdisFSendNetBufferLists+0xc0:<br>&gt; fffff80745e9de30 4c8b5818 mov r11,qword ptr [rax+18h]
> ds:002b:6b49534e02130030=????????????????<br>&gt; Resetting default scope<br>&gt;<br>&gt; CPU_COUNT: 4<br>&gt;<br>&gt; CPU_MHZ: c79<br>&gt;<br>&gt; CPU_VENDOR: GenuineIntel<br>&gt;<br>&gt; CPU_FAMILY: 6<br>&gt;<br>&gt; CPU_MODEL: 3a<br>&gt;<br>&gt; CPU_STEPPING: 9<br>&gt;<br>&gt; CPU_MICROCODE: 6,3a,9,0 (F,M,S,R) SIG: 1B'00000000 (cache) 1B'00000000<br>&gt; (init)<br>&gt;<br>&gt; CUSTOMER_CRASH_COUNT: 1<br>&gt;<br>&gt; DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT<br>&gt;<br>&gt; BUGCHECK_STR: 0x3B<br>&gt;<br>&gt; PROCESS_NAME: EapolLogin.exe<br>&gt;<br>&gt; CURRENT_IRQL: 0<br>&gt;<br>&gt; ANALYSIS_SESSION_HOST: AKISN0W-PC<br>&gt;<br>&gt; ANALYSIS_SESSION_TIME: 02-26-2016 13:42:06.0762<br>&gt;<br>&gt; ANALYSIS_VERSION: 10.0.10586.567 amd64fre<br>&gt;<br>&gt; LAST_CONTROL_TRANSFER: from fffff807476f67f8 to fffff80745e9de30<br>&gt;<br>&gt; STACK_TEXT:<br>&gt; ffffa380027037e0 fffff807476f67f8 : 0000000000000000 0000000000000000<br>&gt; 0000000000000001 ffffd5073a613570 : ndis!NdisFSendNetBufferLists+0xc0<br>&gt; ffffa38002703860 fffff8038c698c05 : ffffd5073a6134a0 0000000000000000<br>&gt; 0000000000000001 fffff68000003140 : npf!NPF_Write+0x214<br>&gt; [j:\npcap\packetwin7\npf\npf\write.c @ 324]<br>&gt; ffffa380027038d0 fffff8038c69840a : ffffd50739edba60 ffffd5073a6134a0<br>&gt; ffffd5072871aef0 ffffa38002703b80 : nt!IopSynchronousServiceTail+0x1a5<br>&gt; ffffa38002703990 fffff8038c3d2f83 : ffff82081164b160 0000000000000000<br>&gt; 0000000000000000 0000000000000000 : nt!NtWriteFile+0x67a<br>&gt; ffffa38002703a90 00007fff94c21034 : 0000000000000000 0000000000000000<br>&gt; 0000000000000000 0000000000000000 : nt!KiSystemServiceCopyEnd+0x13<br>&gt; 000000000014e248 0000000000000000 : 0000000000000000 0000000000000000<br>&gt; 0000000000000000 0000000000000000 : 0x00007fff94c21034
>
>
> THREAD_SHA1_HASH_MOD_FUNC: 8de63a100febe6f9f89153a5a9abc9ba86d452de
>
> THREAD_SHA1_HASH_MOD_FUNC_OFFSET: c12fe9b8d789ae102dec8036452ef91cdcd180b3
>
> THREAD_SHA1_HASH_MOD: bccfea03237cfde6486a55b63bb95e3341833378
>
> FOLLOWUP_IP:
> npf!NPF_Write+214 [j:\npcap\packetwin7\npf\npf\write.c @ 324]
> fffff807`476f67f8 8b6c2478 mov ebp,dword ptr [rsp+78h]
>
> FAULT_INSTR_CODE: 78246c8b
>
> FAULTING_SOURCE_LINE: j:\npcap\packetwin7\npf\npf\write.c
>
> FAULTING_SOURCE_FILE: j:\npcap\packetwin7\npf\npf\write.c
>
> FAULTING_SOURCE_LINE_NUMBER: 324
>
> FAULTING_SOURCE_CODE:
> 320: NDIS_DEFAULT_PORT_NUMBER,
> 321: SendFlags);
> 322: }
> 323:
> > 324: numSentPackets ++;
> 325: }
> 326: else
> 327: {
> 328: //
> 329: // no packets are available in the Transmit pool, wait
> some time. The
>
>
> SYMBOL_STACK_INDEX: 1
>
> SYMBOL_NAME: npf!NPF_Write+214
>
> FOLLOWUP_NAME: MachineOwner
>
> MODULE_NAME: npf
>
> IMAGE_NAME: npf.sys
>
> DEBUG_FLR_IMAGE_TIMESTAMP: 56c2d58e
>
> STACK_COMMAND: .cxr 0xffffa38002702de0 ; kb
>
> BUCKET_ID_FUNC_OFFSET: 214
>
> FAILURE_BUCKET_ID: 0x3B_npf!NPF_Write
>
> BUCKET_ID: 0x3B_npf!NPF_Write
>
> PRIMARY_PROBLEM_CLASS: 0x3B_npf!NPF_Write
>
> TARGET_TIME: 2016-02-26T02:30:30.000Z
>
> OSBUILD: 14267
>
> OSSERVICEPACK: 0
>
> SERVICEPACK_NUMBER: 0
>
> OS_REVISION: 0
>
> SUITE_MASK: 272
>
> PRODUCT_TYPE: 1
>
> OSPLATFORM_TYPE: x64
>
> OSNAME: Windows 10
>
> OSEDITION: Windows 10 WinNt TerminalServer SingleUserTS
>
> OS_LOCALE:
>
> USER_LCID: 0
>
> OSBUILD_TIMESTAMP: 2016-02-13 20:56:11
>
> BUILDDATESTAMP_STR: 160213-0213
>
> BUILDLAB_STR: rs1_release
>
> BUILDOSVER_STR: 10.0.14267.1000.amd64fre.rs1_release.160213-0213
>
> ANALYSIS_SESSION_ELAPSED_TIME: 127c9
>
> ANALYSIS_SOURCE: KM
>
> FAILURE_ID_HASH_STRING: km:0x3b_npf!npf_write
>
> FAILURE_ID_HASH: {2eb5e15e-9853-313b-618d-2ac277a2bfb5}
>
> Followup: MachineOwner
> The source code line pointed in the above dump analysis report is not very
> precise. It’s actually the line above numSentPackets ++;
>
> So the below code triggers BSoD.
>
> NdisFSendNetBufferLists(Open->AdapterHandle,
> pNetBufferList,
> NDIS_DEFAULT_PORT_NUMBER,
> SendFlags);
> It’s understandable the disable behavior of the adapter causes this BSoD,
> as if you have disabled an adapter, you should fail to send packets to it.
> I can’t stop a user disable his adapter when using my driver. But I think
> the only thing should happen in that condition is failing the sending
> action. A BSoD is too much.
>
> So, what I want to know is what’s the correct way to let my driver prevent
> this according to NDIS’s design? Thanks!
>
> —
> NTDEV is sponsored by OSR
>
> Visit the list online at: <
> http://www.osronline.com/showlists.cfm?list=ntdev&gt;
>
> MONTHLY seminars on crash dump analysis, WDF, Windows internals and
> software drivers!
> Details at http:
>
> To unsubscribe, visit the List Server section of OSR Online at <
> http://www.osronline.com/page.cfm?name=ListServer&gt;
>


Bercea. G.</http:>