none
SerEnum sample driver cause system BSOD (IRQL NOT LESS OR EQUAL) RRS feed

  • Question

  • Hi, I am trying to build a serial enum driver for debug legacy device pnp process.

    I use wdk sample (8.1)for w7, wdk sample (10) for w10. 

    But after I installed my test enum driver with serial driver. It always get BSOD in boot process if the legacy device is connected.

    The error message is IRQL NOT LESS OR EQUAL. The same situation on w7 and w10. 

    I only build and modify the target *.sys name. It seems happened on both release/debug mode. 

    The crash dump shows it was crash at serenum_pdo_pnp.

    Is anyone can solve this issue?? 

    BTW, the sample driver also cause BSOD(BAD_POOL_CALLER) when I try to uninstall the test driver...

    Thursday, November 2, 2017 8:54 AM

Answers

  • It is a bug in serenum or your Driver, either way you need to debug it, especially considering serenum works with the in box serial driver. This is not an inf configuration problem

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by CC, Chen Wednesday, November 8, 2017 3:47 AM
    Monday, November 6, 2017 2:31 PM

All replies

  • Debug it. Look at the locals. What does !analyze -v say?

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Thursday, November 2, 2017 3:38 PM
  • Hi 

    The analyzed message (Stack Text trimmed): 

    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    IRQL_NOT_LESS_OR_EQUAL (a)
    An attempt was made to access a pageable (or completely invalid) address at an
    interrupt request level (IRQL) that is too high.  This is usually
    caused by drivers using improper addresses.
    If a kernel debugger is available get the stack backtrace.
    Arguments:
    Arg1: 0000000000000000, memory referenced
    Arg2: 0000000000000002, IRQL
    Arg3: 0000000000000000, bitfield :
    bit 0 : value 0 = read operation, 1 = write operation
    bit 3 : value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
    Arg4: fffff80002c79a75, address which referenced memory

    Debugging Details:
    ------------------


    READ_ADDRESS:  0000000000000000 

    CURRENT_IRQL:  2

    FAULTING_IP: 
    nt!KeSetEvent+1e3
    fffff800`02c79a75 488b00          mov     rax,qword ptr [rax]

    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

    BUGCHECK_STR:  0xA

    PROCESS_NAME:  System

    TRAP_FRAME:  fffff880031af0c0 -- (.trap 0xfffff880031af0c0)
    NOTE: The trap frame does not contain all registers.
    Some register values may be zeroed or incorrect.
    rax=0000000000000000 rbx=0000000000000000 rcx=fffffa80043c05c0
    rdx=0000000000000001 rsi=0000000000000000 rdi=0000000000000000
    rip=fffff80002c79a75 rsp=fffff880031af250 rbp=0000000000000000
     r8=0000000000000000  r9=fffffa8003210bf0 r10=0000000000000000
    r11=0000000000000000 r12=0000000000000000 r13=0000000000000000
    r14=0000000000000000 r15=0000000000000000
    iopl=0         nv up ei pl nz na pe cy
    nt!KeSetEvent+0x1e3:
    fffff800`02c79a75 488b00          mov     rax,qword ptr [rax] ds:00000000`00000000=????????????????
    Resetting default scope

    LOCK_ADDRESS:  fffff80002e7ec60 -- (!locks fffff80002e7ec60)

    Resource @ nt!PiEngineLock (0xfffff80002e7ec60)    Exclusively owned
        Contention Count = 5
        NumberOfExclusiveWaiters = 1
         Threads: fffffa80030fbb50-01<*> 
         Threads Waiting On Exclusive Access:
                  fffffa8003100170       

    1 total locks, 1 locks currently held

    PNP_TRIAGE: 
    Lock address  : 0xfffff80002e7ec60
    Thread Count  : 1
    Thread address: 0xfffffa80030fbb50
    Thread wait   : 0x15e

    LAST_CONTROL_TRANSFER:  from fffff80002c74f29 to fffff80002c75980

    STACK_COMMAND:  kb

    FOLLOWUP_IP: 
    nuvserenum!Serenum_PDO_PnP+c83 [d:\workspace\driver\asus_dis_meter\win7\serenum sample\c++\pnp.c @ 1319]
    fffff880`03f9e153 8b442430        mov     eax,dword ptr [rsp+30h]

    FAULTING_SOURCE_CODE:  
      1315: 
      1316:    Irp->IoStatus.Status = status;
      1317:    IoCompleteRequest (Irp, IO_NO_INCREMENT);
      1318:    IoReleaseRemoveLock(&commonData->RemoveLock,Irp);
    > 1319:    return status;
      1320: }
      1321: 
      1322: NTSTATUS
      1323: Serenum_PnPRemove (PDEVICE_OBJECT Device, PPDO_DEVICE_DATA PdoData)
      1324: /*++


    SYMBOL_STACK_INDEX:  5

    SYMBOL_NAME:  nuvserenum!Serenum_PDO_PnP+c83

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: nuvserenum

    IMAGE_NAME:  nuvserenum.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  59fac460

    FAILURE_BUCKET_ID:  X64_0xA_nuvserenum!Serenum_PDO_PnP+c83

    BUCKET_ID:  X64_0xA_nuvserenum!Serenum_PDO_PnP+c83

    Followup: MachineOwner

    ===================================================

    Thanks.

    Friday, November 3, 2017 9:25 AM
  • It is a null deref, debug it

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, November 3, 2017 2:52 PM
  • It is a null deref, debug it

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Hi Holan,

    The serenum driver code was build from WDK sample and did not modify anything. Why it has null de-ref problem? 

    Or there is something wrong that I hang it as the upper filter driver to the serial driver? Should I provide the INF for investigation?

    Thanks a lot.

    Monday, November 6, 2017 3:33 AM
  • It is a bug in serenum or your Driver, either way you need to debug it, especially considering serenum works with the in box serial driver. This is not an inf configuration problem

    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    • Marked as answer by CC, Chen Wednesday, November 8, 2017 3:47 AM
    Monday, November 6, 2017 2:31 PM
  • Hi Chen,

    Did you solve the problem? If not, can you run driver verifier on those drivers with /standard flags?

    Cheers,

    James

    Saturday, November 18, 2017 4:48 AM
  • Hi James

    We just marked the null-ref code but I still don't know why the irp becomes null when the sample code released it or system called it at wrong IRQL?

    It seems works fine (passed the HLK DF tests).

    // IoReleaseRemoveLock(&commonData->RemoveLock,Irp); 

    Thanks a lot for your kindly reply.

    Monday, November 20, 2017 2:43 AM