Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...

Please check out the Community Guidelines in the Announcements and Administration Category.

More Info on Driver Writing and Debugging

The free OSR Learning Library has more than 50 articles on a wide variety of topics about writing and debugging device drivers and Minifilters. From introductory level to advanced. All the articles have been recently reviewed and updated, and are written using the clear and definitive style you've come to expect from OSR over the years.

Check out The OSR Learning Library at:

WFP driver causing dump in tcpip.sys

Pluto_KoderPluto_Koder Member - All Emails Posts: 7
We have a WFP driver used for packet scanning functionality.
Following is the packet flow:

1: Packet is received in streamclassify function.
2: Packet is cloned(using FwpsCloneStreamData) and added in a packet scanning queue for processing
3: The packet is blocked and absorbed :
pClassifyOut->actionType = FWP_ACTION_BLOCK;
pClassifyOut->rights &= ~FWPS_RIGHT_ACTION_WRITE;
4: streamclassify function returns

In Packet processing thread:
1: Send cloned packet to user mode processing.
2: Receive the scan completion notification.
3: Re-inject packet using FwpsStreamInjectAsync().
4: Discard cloned packet using FwpsDiscardClonedStreamData.

This flow usually works fine. But in one case where a 3p Firewall is installed , the system crashes with BSOD.
Following is the snippet of memory dump:

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.
Arg1: 000000000000003c, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff804992f3fa0, address which referenced memory

fffff803`89e790b0 fffff804`992f2fdd : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : tcpip!TcpBeginTcbSend+0x2c0
fffff803`89e79330 fffff804`992efadb : ffff8a07`00000000 00000000`00000001 ffff8a07`f533a950 fffff803`87b7d6a6 : tcpip!TcpTcbSend+0x2fd
fffff803`89e796b0 fffff804`992ec62d : 00000000`0019b99d 00000000`0019b99d ffff8a07`f5551fa2 ffff8a07`f2541010 : tcpip!TcpFlushDelay+0x1fb
fffff803`89e79730 fffff804`993187e2 : ffff8a07`f2512420 00000000`00000000 fffff803`00000000 ffff8a07`effc1850 : tcpip!TcpReceive+0x37d
fffff803`89e79800 fffff804`992c97fe : 00000000`00000001 fffff804`9954128e fffff803`89e798c9 ffff8a07`f70b2c70 : tcpip!TcpNlClientReceiveDatagrams+0x22
fffff803`89e79840 fffff804`992c9453 : 00000000`00000000 00000000`00000000 fffff803`89e799d0 fffff804`99464000 : tcpip!IppDeliverListToProtocol+0x6a
fffff803`89e79900 fffff804`992e9c8f : fffff803`89e79a09 fffff804`98c07043 00000000`00000000 00000000`00000000 : tcpip!IppProcessDeliverList+0x63
fffff803`89e79970 fffff804`992e9767 : fffff804`99464000 ffff8a07`f2481940 00000000`00000000 ffff8a07`f5bd4000 : tcpip!IppReceiveHeaderBatch+0x25f
fffff803`89e79a70 fffff804`992eb8eb : ffff8a07`f5bf9a40 ffff8a07`f535a030 ffff8a07`f5be7901 ffff8a07`f533bd00 : tcpip!IppFlcReceivePacketsCore+0x317
fffff803`89e79b90 fffff804`992ea747 : ffff8a07`f5bf9a40 fffff803`89e79df0 fffff804`99304c00 00000000`00000002 : tcpip!IpFlcReceivePreValidatedPackets+0x9fb
fffff803`89e79d90 fffff803`87b1140b : ffff8a07`efff8850 fffff803`87eb3380 fffff804`992ea640 fffff803`89e7a060 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x107
fffff803`89e79ec0 fffff803`87b1136d : ffff8a07`f2479820 00000000`00000000 00000000`00000002 00000000`00000000 : nt!KeExpandKernelStackAndCalloutInternal+0x8b
fffff803`89e79f10 fffff804`99304907 : ffff9b00`01c74900 fffff803`87a1ed5f ffff8a07`ed210580 fffff803`87cc20d8 : nt!KeExpandKernelStackAndCalloutEx+0x1d
fffff803`89e79f50 fffff804`99303f83 : 00000000`00000001 fffff803`89e7a0b0 ffff8a07`f5be79c0 fffff804`99541751 : tcpip!NetioExpandKernelStackAndCallout+0x87
fffff803`89e79fb0 fffff804`98c04fae : 00000000`00000001 00000000`00000001 00000000`00000001 fffff803`89e7a350 : tcpip!FlReceiveNetBufferListChain+0x243
fffff803`89e7a1e0 fffff804`98c04c81 : ffff8a07`f5d93c01 00000000`00000000 00000000`00000000 00000000`00000001 : ndis!ndisMIndicateNetBufferListsToOpen+0x13e
fffff803`89e7a2b0 fffff804`98c05583 : ffff8a07`f4d7c1a0 00000000`00018001 fffff804`98c04a50 fffff804`98d4458a : ndis!ndisMTopReceiveNetBufferLists+0x231
fffff803`89e7a3b0 fffff804`98c0498e : ffff8a07`f664c330 ffff8a07`f50bb780 fffff803`87000000 00000000`00000000 : ndis!ndisCallReceiveHandler+0x43
fffff803`89e7a400 fffff804`9b0bf1a6 : fffff804`98e51750 ffff8a07`f4c5ce50 ffff8a07`f52d0300 00000000`00000001 : ndis!NdisMIndicateReceiveNetBufferLists+0x5ae
fffff803`89e7a570 fffff804`9b0a2844 : fffff804`98e516a0 fffff804`98e51601 00000000`00000002 ffff8a07`f5251000 : rt640x64+0x1f1a6
fffff803`89e7a790 fffff804`98bfa4cd : 00000000`00000000 ffff8a07`f5bb5010 00000000`00000000 00000000`00000000 : rt640x64+0x2844
fffff803`89e7a800 fffff803`87b49b72 : 00000000`00000000 00000000`00000000 fffff803`00000000 ffff8a07`00000002 : ndis!ndisInterruptDpc+0x17d
fffff803`89e7a920 fffff803`87b4926f : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiExecuteAllDpcs+0x1d2
fffff803`89e7aa60 fffff803`87c13fca : 00000000`00000000 fffff803`87874180 00000000`001a6f89 fffff803`87eb3380 : nt!KiRetireDpcList+0xdf
fffff803`89e7ac60 00000000`00000000 : fffff803`89e7b000 fffff803`89e75000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a

Can anyone suggest what could be the possible cause?


  • jolyon_wrightjolyon_wright Member - All Emails Posts: 29


    try putting driver verifier on your driver - this may be pick up the problem *before* it hits the system driver and give you a more useful stack trace

    hope this helps

  • Pluto_KoderPluto_Koder Member - All Emails Posts: 7
    Thanks for the reply.

    I have already tried with driver verifier and similar dumps are generated with no addition info related to our WFP driver.
    I am not sure if I am doing the packet block->absorb->process->reinject in a correct way. Do i need to do some stuff other that FwpsCloneStreamData to make sure the reinjected nbls remain valid? I have trief using FwpsReferenceNetBufferList function but it did not solve the issue.

    Or can anyone suggest me the correct or safe way for this.?

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. Sign in or register to get started.

Upcoming OSR Seminars
OSR has suspended in-person seminars due to the Covid-19 outbreak. But, don't miss your training! Attend via the internet instead!
Internals & Software Drivers 7 February 2022 Live, Online
Kernel Debugging 21 March 2022 Live, Online
Developing Minifilters 23 May 2022 Live, Online
Writing WDF Drivers 12 September 2022 Live, Online