none
IRQL_NOT_EQUAL_OR_LESS - NDIS 6.20

    Question

  • Hello, I am new to NDIS and still learning it. I am trying to write a basic virtual miniport driver from start to get better idea of the NDIS. I have written a starting code which contains the required NDIS functions with no real work (just return from the function or return's status) inside their definition along with required OIDs. My plan is to populate the code slowly so that I can understand what is happening and why. But the problem is whenever I am trying to load the driver it is getting BSOD saying IRQL_NOT_EQUAL_OR_LESS_THAN. I know this message is due to illegal pointer access. But as I haven't done anything in the function (except DbgPrint :D), I am wondering where I might go wrong. I have just used the MP Chars Structure & register the driver with ndis function. In win7 if I remove the *NdisMedium, *IfType from the ini file then the driver loads and then immediately unloads without giving any BSOD. But it fails when I put them there. So, I was wondering is it possible to do nothing (even in MPInitializeEx) in callback functions. And if it is possible then can anyone suggest where I might go wrong. Thank you in advance & sorry for my english. regards,
    fadedreamz
    Thursday, April 21, 2011 4:17 AM

Answers

  • Just to inform,

    I have found out the problem which was causing the crash. The NDIS_HANDLE which is passed by NDIS in MPInitializeEx (driver's function) should be set by driver resident structure. Because in later that resident handle will be passed to other driver functions like MPCheckForHangEx and so on. After setting the context the crash is now gone, windows loads the driver (though nothing is there except DbgPrint :) ). May be NDIS access that handler internally after MPInitializeEx returns with a NDIS_STATUS_SUCCESS.

     

    Thanks to everyone for their valuable opinion.

    regards,


    fadedreamz
    • Marked as answer by fadedreamz Sunday, May 01, 2011 12:15 PM
    Sunday, May 01, 2011 12:15 PM

All replies

  • Hi, Let's start with the basics. Are you using WinDbg[1] to debug your driver? With the debugger attached to your test machine, you will get more detailed error analysis than just IRQL_NOT_EQUAL_OR_LESS_THAN. See kernel_debugging_tutorial.doc on the debugger installation folder to get started with kernel debugging. -- Antti [1] http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
    Thursday, April 21, 2011 5:08 AM
  • Hi, Let's start with the basics. Are you using WinDbg[1] to debug your driver? With the debugger attached to your test machine, you will get more detailed error analysis than just IRQL_NOT_EQUAL_OR_LESS_THAN. See kernel_debugging_tutorial.doc on the debugger installation folder to get started with kernel debugging. -- Antti [1] http://msdn.microsoft.com/en-us/windows/hardware/gg463009.aspx
    Hi Antti, Thank you for your reply. Yes, I am using virtual KD and VMPlayer to debug. I have setup the symbol server. And also setup a breakpoint while loading the module (bu test). But the system crashes before the breakpoint occurs. It seems that the error occurs while loading the driver. !analyze -v shows more versobe output and calling stack. But I cannot find my module's function there :( . If you have suggestion on debugging (which info to look), please let me know. I am using win7 x64 dev machine & win7 x86 target machine in VMPlayer. Thanks again & regards,
    fadedreamz
    Thursday, April 21, 2011 5:16 AM
  • post the output of !analyze -v here (make sure your symbols are correct first, otherwise it will be meaningless)
    d -- This posting is provided "AS IS" with no warranties, and confers no rights.
    Thursday, April 21, 2011 5:35 AM
    Owner
  • Hello, I am new to NDIS and still learning it. I am trying to write a basic virtual miniport driver from start to get better idea of the NDIS. I have written a starting code which contains the required NDIS functions with no real work (just return from the function or return's status) inside their definition along with required OIDs. My plan is to populate the code slowly so that I can understand what is happening and why. But the problem is whenever I am trying to load the driver it is getting BSOD saying IRQL_NOT_EQUAL_OR_LESS_THAN. I know this message is due to illegal pointer access. But as I haven't done anything in the function (except DbgPrint :D), I am wondering where I might go wrong. I have just used the MP Chars Structure & register the driver with ndis function. In win7 if I remove the *NdisMedium, *IfType from the ini file then the driver loads and then immediately unloads without giving any BSOD. But it fails when I put them there. So, I was wondering is it possible to do nothing (even in MPInitializeEx) in callback functions. And if it is possible then can anyone suggest where I might go wrong. Thank you in advance & sorry for my english. regards,
    fadedreamz

    Hi,

    Would you like a slightly different idea: start with a virtual NDIS miniport from WDK samples. get it running. Watch how OIDs ad other stuff (including debug prints)  work. Then try to tweak and bend it as you need. Step by step. When something breaks, revert the last step. ??

    -- pa

    Thursday, April 21, 2011 7:59 AM
  • Thank you Doron for your reply. This is the output of !analyze -v command ========================================= ******************************************************************************* * * * Bugcheck Analysis * * * ******************************************************************************* SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e) This is a very common bugcheck. Usually the exception address pinpoints the driver/function that caused the problem. Always note this address as well as the link date of the driver/image that contains this address. Arguments: Arg1: c0000005, The exception code that was not handled Arg2: 829a4382, The address that the exception occurred at Arg3: 955525e0, Exception Record Address Arg4: 955521c0, Context Record Address Debugging Details: ------------------ DBGHELP: c:\symbols\ntkrpamp.exe\4A5BC007410000\ntkrpamp.exe - OK EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. FAULTING_IP: nt!IopLoadDriver+448 829a4382 0fb74844 movzx ecx,word ptr [eax+44h] EXCEPTION_RECORD: 955525e0 -- (.exr 0xffffffff955525e0) ExceptionAddress: 829a4382 (nt!IopLoadDriver+0x00000448) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000000 Parameter[1]: 00000044 Attempt to read from address 00000044 CONTEXT: 955521c0 -- (.cxr 0xffffffff955521c0) eax=00000000 ebx=00000000 ecx=aaccad00 edx=9b7f9000 esi=82967820 edi=00000000 eip=829a4382 esp=955526a8 ebp=9555287c iopl=0 nv up ei pl nz ac po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010212 nt!IopLoadDriver+0x448: 829a4382 0fb74844 movzx ecx,word ptr [eax+44h] ds:0023:00000044=???? Resetting default scope PROCESS_NAME: System CURRENT_IRQL: 2 ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s. EXCEPTION_PARAMETER1: 00000000 EXCEPTION_PARAMETER2: 00000044 READ_ADDRESS: 00000044 FOLLOWUP_IP: nt!IopLoadDriver+448 829a4382 0fb74844 movzx ecx,word ptr [eax+44h] BUGCHECK_STR: 0x7E DEFAULT_BUCKET_ID: NULL_CLASS_PTR_DEREFERENCE LOCK_ADDRESS: 82966f60 -- (!locks 82966f60) Resource @ nt!PiEngineLock (0x82966f60) Exclusively owned Contention Count = 4 Threads: 8fc98a68-01<*> 1 total locks, 1 locks currently held PNP_TRIAGE: Lock address : 0x82966f60 Thread Count : 1 Thread address: 0x8fc98a68 Thread wait : 0x36e1 LAST_CONTROL_TRANSFER: from 828dde71 to 8286c394 STACK_TEXT: 9555287c 829abfe7 00000000 00000000 955528a4 nt!IopLoadDriver+0x448 95552928 829f0e4e 9d1baba0 00000001 9d1bab94 nt!PipCallDriverAddDeviceQueryRoutine+0x34b 95552960 829f90a2 00000001 95552a2c c0000034 nt!RtlpCallQueryRegistryRoutine+0x2cd 955529cc 829a9108 40000000 8000051c 95552a48 nt!RtlQueryRegistryValues+0x31d 95552aa8 829a8876 9098c918 95552cd0 8f7a3490 nt!PipCallDriverAddDevice+0x383 95552ca4 829b1669 9098c918 8f7a3490 95552cd0 nt!PipProcessDevNodeTree+0x15d 95552cd8 82814f53 82964e80 8fc98a68 8293b5bc nt!PiRestartDevice+0x8a 95552d00 8286ef2b 00000000 00000000 8fc98a68 nt!PnpDeviceActionWorker+0x1fb 95552d50 82a0f66d 80000001 1c607815 00000000 nt!ExpWorkerThread+0x10d 95552d90 828c10d9 8286ee1e 80000001 00000000 nt!PspSystemThreadStartup+0x9e 00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19 SYMBOL_STACK_INDEX: 0 SYMBOL_NAME: nt!IopLoadDriver+448 FOLLOWUP_NAME: MachineOwner MODULE_NAME: nt IMAGE_NAME: ntkrpamp.exe DEBUG_FLR_IMAGE_TIMESTAMP: 4a5bc007 STACK_COMMAND: .cxr 0xffffffff955521c0 ; kb FAILURE_BUCKET_ID: 0x7E_nt!IopLoadDriver+448 BUCKET_ID: 0x7E_nt!IopLoadDriver+448 Followup: MachineOwner ======================================== If you have any suggestion please let me know. regards,
    fadedreamz
    Thursday, April 21, 2011 12:13 PM
  • Can you please upload the text with \r\n separators?
    It is very hard to read something this way.

    Thanks.

    Alon 

     

    Thursday, April 21, 2011 12:16 PM
  • Can you please upload the text with \r\n separators?
    It is very hard to read something this way.

    Thanks.

    Alon 

     

    Sorry Alon, I did upload it with \r\n but something happened. Anyway, Here is the pastebin link http://pastebin.com/M1vCfDXX regards,
    fadedreamz
    Thursday, April 21, 2011 12:19 PM
  • Hi,

    Now I can see it but it seems that the bug check in the pasted text (SYSTEM_THREAD_EXCEPTION_NOT_HANDLED) is different than the one you have described in your original post (IRQL_NOT_EQUAL_OR_LESS).

    Please also run the command as appear in STACK_COMMAND:  .cxr 0xffffffff955521c0 ; kb

    in this case .cxr 0xffffffff955521c0 ; kb


    Thanks,

    Alon 

     

    Thursday, April 21, 2011 12:26 PM
  • Just to inform,

    I have found out the problem which was causing the crash. The NDIS_HANDLE which is passed by NDIS in MPInitializeEx (driver's function) should be set by driver resident structure. Because in later that resident handle will be passed to other driver functions like MPCheckForHangEx and so on. After setting the context the crash is now gone, windows loads the driver (though nothing is there except DbgPrint :) ). May be NDIS access that handler internally after MPInitializeEx returns with a NDIS_STATUS_SUCCESS.

     

    Thanks to everyone for their valuable opinion.

    regards,


    fadedreamz
    • Marked as answer by fadedreamz Sunday, May 01, 2011 12:15 PM
    Sunday, May 01, 2011 12:15 PM