none
NdisFSendNetBufferLists causes BSoD when the adapter is being disabled RRS feed

  • Question


  • 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:
    fffff807`45e9de30 4c8b5818        mov     r11,qword ptr [rax+18h] ds:002b:6b49534e`02130030=????????????????
    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: 
    ffffa380`027037e0 fffff807`476f67f8 : 00000000`00000000 00000000`00000000 00000000`00000001 ffffd507`3a613570 : ndis!NdisFSendNetBufferLists+0xc0
    ffffa380`02703860 fffff803`8c698c05 : ffffd507`3a6134a0 00000000`00000000 00000000`00000001 fffff680`00003140 : npf!NPF_Write+0x214 [j:\npcap\packetwin7\npf\npf\write.c @ 324]
    ffffa380`027038d0 fffff803`8c69840a : ffffd507`39edba60 ffffd507`3a6134a0 ffffd507`2871aef0 ffffa380`02703b80 : nt!IopSynchronousServiceTail+0x1a5
    ffffa380`02703990 fffff803`8c3d2f83 : ffff8208`1164b160 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtWriteFile+0x67a
    ffffa380`02703a90 00007fff`94c21034 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
    00000000`0014e248 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 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!

    Saturday, February 27, 2016 2:53 PM