Jeremy Drake

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
---------



Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Jeremy Drake

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...





Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Biao Wang [MSFT]

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.





Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Jeremy Drake

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...





Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Biao Wang [MSFT]

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.





Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Jeremy Drake

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.





Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Biao Wang [MSFT]

good to know. thanks Jeremy.





Re: Windows Filtering Platform (WFP) Stop error in Vista with NDIS 5.1 network driver

Jeremy Drake

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.