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:
fffff80389e790b0 fffff804992f2fdd : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : tcpip!TcpBeginTcbSend+0x2c0
fffff80389e79330 fffff804992efadb : ffff8a0700000000 0000000000000001 ffff8a07f533a950 fffff80387b7d6a6 : tcpip!TcpTcbSend+0x2fd
fffff80389e796b0 fffff804992ec62d : 000000000019b99d 000000000019b99d ffff8a07f5551fa2 ffff8a07f2541010 : tcpip!TcpFlushDelay+0x1fb
fffff80389e79730 fffff804993187e2 : ffff8a07f2512420 0000000000000000 fffff80300000000 ffff8a07effc1850 : tcpip!TcpReceive+0x37d
fffff80389e79800 fffff804992c97fe : 0000000000000001 fffff8049954128e fffff80389e798c9 ffff8a07f70b2c70 : tcpip!TcpNlClientReceiveDatagrams+0x22
fffff80389e79840 fffff804992c9453 : 0000000000000000 0000000000000000 fffff80389e799d0 fffff80499464000 : tcpip!IppDeliverListToProtocol+0x6a
fffff80389e79900 fffff804992e9c8f : fffff80389e79a09 fffff80498c07043 0000000000000000 0000000000000000 : tcpip!IppProcessDeliverList+0x63
fffff80389e79970 fffff804992e9767 : fffff80499464000 ffff8a07f2481940 0000000000000000 ffff8a07f5bd4000 : tcpip!IppReceiveHeaderBatch+0x25f
fffff80389e79a70 fffff804992eb8eb : ffff8a07f5bf9a40 ffff8a07f535a030 ffff8a07f5be7901 ffff8a07f533bd00 : tcpip!IppFlcReceivePacketsCore+0x317
fffff80389e79b90 fffff804992ea747 : ffff8a07f5bf9a40 fffff80389e79df0 fffff80499304c00 0000000000000002 : tcpip!IpFlcReceivePreValidatedPackets+0x9fb
fffff80389e79d90 fffff80387b1140b : ffff8a07efff8850 fffff80387eb3380 fffff804992ea640 fffff80389e7a060 : tcpip!FlReceiveNetBufferListChainCalloutRoutine+0x107
fffff80389e79ec0 fffff80387b1136d : ffff8a07f2479820 0000000000000000 0000000000000002 0000000000000000 : nt!KeExpandKernelStackAndCalloutInternal+0x8b
fffff80389e79f10 fffff80499304907 : ffff9b0001c74900 fffff80387a1ed5f ffff8a07ed210580 fffff80387cc20d8 : nt!KeExpandKernelStackAndCalloutEx+0x1d
fffff80389e79f50 fffff80499303f83 : 0000000000000001 fffff80389e7a0b0 ffff8a07f5be79c0 fffff80499541751 : tcpip!NetioExpandKernelStackAndCallout+0x87
fffff80389e79fb0 fffff80498c04fae : 0000000000000001 0000000000000001 0000000000000001 fffff80389e7a350 : tcpip!FlReceiveNetBufferListChain+0x243
fffff80389e7a1e0 fffff80498c04c81 : ffff8a07f5d93c01 0000000000000000 0000000000000000 0000000000000001 : ndis!ndisMIndicateNetBufferListsToOpen+0x13e
fffff80389e7a2b0 fffff80498c05583 : ffff8a07f4d7c1a0 0000000000018001 fffff80498c04a50 fffff80498d4458a : ndis!ndisMTopReceiveNetBufferLists+0x231
fffff80389e7a3b0 fffff80498c0498e : ffff8a07f664c330 ffff8a07f50bb780 fffff80387000000 0000000000000000 : ndis!ndisCallReceiveHandler+0x43
fffff80389e7a400 fffff8049b0bf1a6 : fffff80498e51750 ffff8a07f4c5ce50 ffff8a07f52d0300 0000000000000001 : ndis!NdisMIndicateReceiveNetBufferLists+0x5ae
fffff80389e7a570 fffff8049b0a2844 : fffff80498e516a0 fffff80498e51601 0000000000000002 ffff8a07f5251000 : rt640x64+0x1f1a6
fffff80389e7a790 fffff80498bfa4cd : 0000000000000000 ffff8a07f5bb5010 0000000000000000 0000000000000000 : rt640x64+0x2844
fffff80389e7a800 fffff80387b49b72 : 0000000000000000 0000000000000000 fffff80300000000 ffff8a0700000002 : ndis!ndisInterruptDpc+0x17d
fffff80389e7a920 fffff80387b4926f : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiExecuteAllDpcs+0x1d2
fffff80389e7aa60 fffff80387c13fca : 0000000000000000 fffff80387874180 00000000001a6f89 fffff80387eb3380 : nt!KiRetireDpcList+0xdf
fffff80389e7ac60 0000000000000000 : fffff80389e7b000 fffff80389e75000 0000000000000000 0000000000000000 : nt!KiIdleLoop+0x5a

Can anyone suggest what could be the possible cause?

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

https://docs.microsoft.com/en-us/windows-hardware/drivers/devtest/driver-verifier

hope this helps

jolyon

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,