locked
Stop error in Vista with NDIS 5.1 network driver RRS feed

  • Question

  • One of the people who is now testing my WFP application/callout is experiencing periodic bluescreens (fairly often, generally within a couple hours) while the machine is idle.  The network driver is Rtnicxp.sys, which is a Realtek driver.  The crash dumps are always identical, and happen with versions 6.103 (the version used in the crash below) and also in the current 6.105 version.  Nobody else is having these issues, and the biggest difference between my development environment and his machine is that his is using the NDIS 5.1 compatibility layer for the network driver.

     

    Has anyone seen anything like this before, or know if there is anything I could be doing wrong in my callout driver to cause this?

     

    Thanks,

    Jeremy

     

     

    Code Snippet

    *******************************************************************************
    *                                                                             *
    *                        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: 0000001d, memory referenced
    Arg2: 00000002, IRQL
    Arg3: 00000000, value 0 = read operation, 1 = write operation
    Arg4: 81ac2606, address which referenced memory

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

    *** ERROR: Module load completed but symbols could not be loaded for Rtnicxp.sys

    READ_ADDRESS:  0000001d

    CURRENT_IRQL:  2

    FAULTING_IP:
    ndis!ndisXlateReturnNetBufferListToPacket+25
    81ac2606 f6461d80        test    byte ptr [esi+1Dh],80h

    DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

    BUGCHECK_STR:  0xD1

    PROCESS_NAME:  Idle

    TRAP_FRAME:  81cf1b74 -- (.trap 0xffffffff81cf1b74)
    ErrCode = 00000000
    eax=84aeed18 ebx=00000b01 ecx=84aeed98 edx=00000002 esi=00000000 edi=00000001
    eip=81ac2606 esp=81cf1be8 ebp=81cf1bec iopl=0         nv up ei pl zr na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
    ndis!ndisXlateReturnNetBufferListToPacket+0x25:
    81ac2606 f6461d80        test    byte ptr [esi+1Dh],80h     ds:0023:0000001d=??
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from 81ac2606 to 81c8fc44

    STACK_TEXT: 
    81cf1b74 81ac2606 badb0d00 00000002 00000010 nt!KiTrap0E+0x2ac
    81cf1bec 81b692e7 84aeed18 8492304c 84923000 ndis!ndisXlateReturnNetBufferListToPacket+0x25
    81cf1c28 883d0eb1 00000000 81cf1c48 00000001 ndis!ndisMIndicatePacketsToNetBufferLists+0x10c
    WARNING: Stack unwind information not available. Following frames may be wrong.
    81cf1c58 883d116d 84923000 81fa4e10 84923000 Rtnicxp+0x4eb1
    81cf1c70 883d120b 84923000 84923778 84923000 Rtnicxp+0x516d
    81cf1c94 883cd858 00923000 847a4488 81cf1cc8 Rtnicxp+0x520b
    81cf1ca4 81b62d91 84923000 84923778 847a4488 Rtnicxp+0x1858
    81cf1cc8 81accd18 8492378c 00923778 00000000 ndis!ndisMDpcX+0x7c
    81cf1ce8 81ca93ae 8492378c 84923778 00000000 ndis!ndis5InterruptDpc+0x95
    81cf1d50 81c912ae 00000000 0000000e 00000000 nt!KiRetireDpcList+0x147
    81cf1d54 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x46


    STACK_COMMAND:  kb

    FOLLOWUP_IP:
    Rtnicxp+4eb1
    883d0eb1 8bcf            mov     ecx,edi

    SYMBOL_STACK_INDEX:  3

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME: Rtnicxp

    IMAGE_NAME:  Rtnicxp.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  45b57a6c

    SYMBOL_NAME:  Rtnicxp+4eb1

    FAILURE_BUCKET_ID:  0xD1_Rtnicxp+4eb1

    BUCKET_ID:  0xD1_Rtnicxp+4eb1

    Followup: MachineOwner
    ---------

     

     

     

    Friday, August 24, 2007 9:09 PM

Answers

  • I just figured out that in my NDIS filter driver, I had totally glazed over the fact that I needed to check the NDIS_RECEIVE_FLAGS_RESOURCES flag, and not call NdisFReturnNetBufferLists if it is set.  I just gave a new build of my driver to the one guy who was seeing this, and will see if that is indeed the problem...

    Monday, August 27, 2007 8:15 PM

All replies

  • After further debugging, it appears that this is crashing near my NDIS filter driver component, rather than my WFP component (I also need to filter ARP, so I need to have both).

     

    So, this may be the wrong forum for this issue, but still if anyone knows what's going on, I would appreciate any insights...

    Saturday, August 25, 2007 12:31 AM
  • If not already, try enable driver verifier on both of your drivers (and if you suspect WFP is invovled, enable DV on tcpip.sys, netio.sys, fwpkclnt.sys, and ndis.sys as well).

     

    Biao.W.

    Saturday, August 25, 2007 2:20 AM
  • I just figured out that in my NDIS filter driver, I had totally glazed over the fact that I needed to check the NDIS_RECEIVE_FLAGS_RESOURCES flag, and not call NdisFReturnNetBufferLists if it is set.  I just gave a new build of my driver to the one guy who was seeing this, and will see if that is indeed the problem...

    Monday, August 27, 2007 8:15 PM
  • Speaking of Ndis, we are looking into extending WFP to support Layer 2 inspection (e.g. 802.3/802.11 layers). It would be great if you can share your NDIS filtering requirement so that we can take them into consideration.

     

    Biao.W.

    Monday, August 27, 2007 11:03 PM
  • The ONLY thing that I am using the NDIS filter driver for is to process ARP packets.  Everything else is done using WFP.  It would be very nice if it were possible to do that in WFP...

     

    What I would need is just a callout on ARP packets (incoming and outgoing).  I need to inspect the various fields in the ARP packet (src and dst ip and mac addresses), and use this information to check and update various data structures.  I need to be able to block or allow the packet based on the results of these checks.

     

    Basically the ultimate goal is to block and log unsolicited ARP replies, and to block and log ARP replies which conflict either with what I have recently seen, or with what has been configured in a static table.

    Monday, August 27, 2007 11:18 PM
  • good to know. thanks Jeremy.

     

    Tuesday, August 28, 2007 3:08 AM
  • It would also be nice (though I don't need it for anything but logging) if there were some way to get the network layer headers via the fixed or metadata information for other layers.  The existing code I was porting from older OS versions had access to this information because of the low level at which it operated, but this also resulted in being dependant on only operating on ethernet networks.

     

    So, while hating to code anything specific for one low level protocol, it would be nice to have a generic way to get the headers from a low-level protocol.

    Tuesday, August 28, 2007 5:11 PM