none
IRQL_NOT_LESS_OR_EQUAL RRS feed

  • Question

  • Hi,

    I have a WFP driver that redirects all http packets to another system. I used ddproxy code as a base code and developed over it. so it has a pended packet structure and has a worker thread that takes care of re-injection process.

    Since Pended packet structure uses quite a bit of memory i decided to use a memory manager. This is what i did:

    I allocated a large chunk of memory say 2 pages and gave memory from it to pended packet whenever required. I have checked my memory manager code lots of time and it seems to do what it is suppose to do. But when i start using memory for this chunk, my driver crashes or sometimes tcp.sys or netio.sys (which i am guessing is part of tcp subsystem) and the error that i am getting is this "IRQL_NOT_LESS_OR_EQUAL". My guess is that there is some problem with the ownership transfer.

    Please help...

    Aravind

    Tuesday, June 15, 2010 6:27 AM

All replies

  • Update on the previous thread:

    All the memory that i allocate are in multiples of 8bytes so it is confined to word boundary.

    Any kind of input would be of great help...

    Regards

    Aravind

    Wednesday, June 16, 2010 6:27 AM
  •  

    Aravind, you should post output of !analyze -v here (with correct symbols). Otherwise nobody is able to comment on your problem.

    Regards

    Frank

    Wednesday, June 16, 2010 7:16 AM
  • 0: kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
    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 kernel debugger is available get stack backtrace.
    Arguments:
    Arg1: bda24e4c, memory referenced
    Arg2: 00000002, IRQL
    Arg3: 00000000, value 0 = read operation, 1 = write operation
    Arg4: 85cfefdb, address which referenced memory

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


    READ_ADDRESS: GetPointerFromAddress: unable to read from 82d81718
    Unable to read MiSystemVaType memory at 82d61160
     bda24e4c

    CURRENT_IRQL:  2

    FAULTING_IP:
    tcpip!IppReceiveHeadersHelper+10
    85cfefdb 8b5804          mov     ebx,dword ptr [eax+4]

    CUSTOMER_CRASH_COUNT:  1

    DEFAULT_BUCKET_ID:  VERIFIER_ENABLED_VISTA_MINIDUMP

    BUGCHECK_STR:  0xD1

    PROCESS_NAME:  System

    TRAP_FRAME:  88123be8 -- (.trap 0xffffffff88123be8)
    ErrCode = 00000000
    eax=bda24e48 ebx=00000000 ecx=88123cb0 edx=00000000 esi=8b0c5100 edi=8302c700
    eip=85cfefdb esp=88123c5c ebp=88123c70 iopl=0         nv up ei ng nz ac po nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010292
    tcpip!IppReceiveHeadersHelper+0x10:
    85cfefdb 8b5804          mov     ebx,dword ptr [eax+4] ds:0023:bda24e4c=????????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from 85cfefdb to 82c5f82b

    STACK_TEXT: 
    88123be8 85cfefdb badb0d00 00000000 88123c28 nt!KiTrap0E+0x2cf
    88123c70 85cfed8a 8b0c5100 85d5ed98 88123cb0 tcpip!IppReceiveHeadersHelper+0x10
    88123cc4 85cba872 85d5ed98 88123ce0 87eeafe0 tcpip!IppReceiveHeaderBatch+0x56
    88123cec 82e397fd 8af1bca0 00d5ed98 855e1798 tcpip!IppLoopbackTransmit+0x52
    88123d00 82c86f3b 87eeafe0 00000000 855e1798 nt!IopProcessWorkItem+0x23
    88123d50 82e276bb 00000001 a11d24f5 00000000 nt!ExpWorkerThread+0x10d
    88123d90 82cd90f9 82c86e2e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
    00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x19


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    tcpip!IppReceiveHeadersHelper+10
    85cfefdb 8b5804          mov     ebx,dword ptr [eax+4]

    SYMBOL_STACK_INDEX:  1

    SYMBOL_NAME:  tcpip!IppReceiveHeadersHelper+10

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: tcpip

    IMAGE_NAME:  tcpip.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bbf8e

    FAILURE_BUCKET_ID:  0xD1_VRF_tcpip!IppReceiveHeadersHelper+10

    BUCKET_ID:  0xD1_VRF_tcpip!IppReceiveHeadersHelper+10

    Followup: MachineOwner
    ---------
    Thursday, June 17, 2010 12:57 PM
  • Memory that your are allocating with your "memory-manager" and forwarding to WFP injecting routines (e.g. controlData) is it NonPagedPool or PagedPool?

     

    Friday, June 18, 2010 9:41 AM
  • Its non-paged pool. Also since i am allocating memory from both send and receive direction, should i make my memory manager code thread protected. Not sure if both these packet processing direction executes in different thread context.

     

    Please clarify...

     

    Regards

    Aravin

    Friday, June 18, 2010 11:59 AM
  • Hi All,

    This is all i want to know: Is inbound and outbound packet processing happens in different thread context or same. For example if i made inboud processing to wait indefinitely will still outbound packet processing happen. I am asking this to resolve thread specific data in the memory manager that i have implemented.

     

    Please Help...

     

    Regards

    Aravind

    Thursday, June 24, 2010 4:42 AM
  • With the exception of TCP ACKs, resource deprevation,  power states handling, etc , theoretically you could pend either direction indefinately and still continue to send / receive traffic.

    You can't assume the thread context as in some cases it will occure in the same context and others it will be in the same.

    Hope this helps


    Dusty Harper [MSFT]
    Microsoft Corporation
    ------------------------------------------------------------
    This posting is provided "AS IS", with NO warranties and confers NO rights
    ------------------------------------------------------------
    Friday, July 2, 2010 12:22 AM
    Moderator
  • Hi Mr.Harper,

    So the advice is to protect my memory manager with semaphores as both send and receive directions uses it to allocate memory.

    Is there anyplace i could understand the actual processing that happens in TCP stack and how each packet processing happens independently and concurrently.

    -Update

    I have protected Memory Manager with semaphores and everything seems to work fine. But i wanted to confirm this and get more understanding on the underlying logic.

    Please Help...

    -Aravind

    Friday, July 2, 2010 6:09 AM