Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Go Back   OSR Online Lists > windbg
Welcome, Guest
You must login to post to this list
  Message 1 of 3  
06 Feb 18 02:00
Pluto Koder
Join Date: 06 Feb 2018
Posts To This List: 6
WFP driver causing dump in tcpip.sys

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->flags |= FWPS_CLASSIFY_OUT_FLAG_ABSORB; 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: 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: 000000000000003c, memory referenced Arg2: 0000000000000002, IRQL Arg3: 0000000000000001, value 0 = read operation, 1 = write operation Arg4: fffff804992f3fa0, address which referenced memory STACK_TEXT: 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?
  Message 2 of 3  
06 Feb 18 02:34
jolyon wright
Join Date: 07 Mar 2016
Posts To This List: 4
WFP driver causing dump in tcpip.sys

no. but. 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 jolyon
  Message 3 of 3  
08 Feb 18 13:45
Pluto Koder
Join Date: 06 Feb 2018
Posts To This List: 6
WFP driver causing dump in tcpip.sys

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.? Thanks,
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the windbg list to be able to post.

All times are GMT -5. The time now is 02:28.

Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license