本文介绍了WFP驱动程序BSOD位于FwpsInjectTransportReceiveAsync0的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述





我们有一个基于检查WDK样本的WFP驱动程序。

在堆栈中我们可以看到mydriver!WFPCloneReinjectInbound + 0x18c我正在调用FwpsInjectTransportReceiveAsync0函数。



BAD_POOL_CALLER(c2)

当前线程正在发出错误的池请求。  通常这是一个错误的IRQL级别或双重释放相同的分配等。

参数:

Arg1:0000000000000007,尝试释放已释放的池

Arg2:0000000000001200,(保留)

Arg3:0000000000000000,池块的内存内容

Arg4:ffffe00005c8e168,池块的地址被解除分配



调试细节:

------------------



$
POOL_ADDRESS:  ffffe00005c8e168 



FREED_POOL_TAG:  NDnd



BUGCHECK_STR:  0xc2_7_NDnd



DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT



PROCESS_NAME: 系统



CURRENT_IRQL:  2



ANALYSIS_VERSION: 6.3.9600.17029(调试器(dbg).140219-1702)amd64fre



LAST_CONTROL_TRANSFER: 从fffff8001d714f5c到fffff8001d5c38a0



STACK_TEXT:& n $; b $ b ffffd000`218881c8 fffff800`1d714f5c:00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00000000:nt!KeBugCheckEx

ffffd000`218881d0 fffff800`52303653:00000000` 00000000 ffffe000`049b0500 ffffe000`049a1390 00000000`00000000:nt!ExDeferredFreePool + 0x6ec

ffffd000`218882c0 fffff800`53383455:00000000`00000000 fffff800`534fa6fd 00000000`00000000 00000000`00000000:NETIO!NetioFreeMdl + 0x232d3

ffffd000`21888310 fffff800`522d9142:ffffe000`031e3500 00000000`00000001 00000000`00000000 00000000`00000000:tcpip!FlpReturnNetBufferListChain + 0x8b585

ffffd000`21888360 fffff800`522d53a2:00000000`00000000 ffffe000`049b05f0 00000000`00000000 ffffe000`050ee140:NETIO!NetioDereferenceNetBufferList + 0xb2

ffffd000`218883a0 fffff800`532fad53:00000000`00000000 ffffd000`21888400 00000000`00000000 00000000`00000000:NETIO!NetioDereferenceNetBufferListChain + 0x2e2

ffffd000`21888440 fffff800`532f9040:fffff800`5344 b180 ffffe000`050ee140 ffffe000`024e0000 ffffe000`024e0000:tcpip!IppReceiveHeaderBatch + 0x323

ffffd000`21888560 fffff800`533edd30:ffffe000`03488bd0 00000000`00000000 00000000`00000001 00000000`00000000:tcpip!IppFlcReceivePacketsCore + 0x680

ffffd000`218888e0 fffff800`534fa2fd:ffffe000`04ae2902 ffffe000`02375c10 ffffd000`21888bb9 ffffd000`21883000:tcpip!IppInspectInjectReceive + 0x148

ffffd000`21888940 fffff800`1d52ef63:00000000`00000000 00000000`00000000 00000000`00000000 fffff800`534fa7c0:fwpkclnt!FwppInjectionStackCallout + 0xe5

ffffd000`218889d0 fffff800`5350b7ae:fffff800`534fa218 ffffd000`21888b40 00000000`00000010 ffffe000`03b32c70:nt!KeExpandKernelStackAndCalloutInternal + 0xf3

ffffd000`21888ac0 fffff800`52d0231c:ffffe000`03b32c70 00000000`00000000 ffffe000`049b0700 ffffe000`02e42650:fwpkclnt!FwpsInjectTransportReceiveAsync0 + 0x2ea

ffffd000`21888c00 fffff800`52d026ed:ffffe000`050ee140 ffffe000 `02e42650 ffff f800`52d06e10 00000000`00000000:mydriver!WFPCloneReinjectInbound + 0x18c

ffffd000`21888c80 fffff800`1d571554:ffffe000`03b33880 ffffe000`02e42650 00000000`00000080 00000000`00000001:mydriver!WFP_AuthenticateThread + 0x315

ffffd000`21888d40 fffff800`1d5c9ec6:ffffd000`205ce180 ffffe000`03b33880 ffffd000`205da240 00000000`00005000:nt!PspSystemThreadStartup + 0x58

ffffd000`21888da0 00000000`00000000:ffffd000`21889000 ffffd000`21883000 00000000 `00000000 00000000`00000000:nt!KiStartSystemThread + 0x16



有些观察结果可能有所帮助:



- >有时当我们将数据包挂在ALE AUTH RECIEVE(INBOUND)然后在单独的线程中处理数据包然后重新注入它时会对NET_BUFFER_LIST进行处理。

   因为这种情况有时只会发生,所以当我们试图推迟BSOD时.B


- >该机器安装了NSClient ++。据观察,当nscp.exe在端口5666连接时,在服务器进程中它是5666端口的INBOUND,并且在重新注入数据包的同时  dereferences.A卸载NSClient ++
后,这个问题也很少发生。



- >我想知道在什么条件下发生了derefernce,以便我可以在以后针对该特定情况自行省略解除引用。



- >通过谷歌搜索我可以找到很多这样的情况,其中WFP驱动程序崩溃类似,但解决方案只是卸载特定的驱动程序。



Windows开发人员

Hi

We have a WFP driver based on inspect WDK sample.
As in stack we can see mydriver!WFPCloneReinjectInbound+0x18c I am making an call to FwpsInjectTransportReceiveAsync0 function.

BAD_POOL_CALLER (c2)
The current thread is making a bad pool request.  Typically this is at a bad IRQL level or double freeing the same allocation, etc.
Arguments:
Arg1: 0000000000000007, Attempt to free pool which was already freed
Arg2: 0000000000001200, (reserved)
Arg3: 0000000000000000, Memory contents of the pool block
Arg4: ffffe00005c8e168, Address of the block of pool being deallocated

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


POOL_ADDRESS:  ffffe00005c8e168 

FREED_POOL_TAG:  NDnd

BUGCHECK_STR:  0xc2_7_NDnd

DEFAULT_BUCKET_ID:  WIN8_DRIVER_FAULT

PROCESS_NAME:  System

CURRENT_IRQL:  2

ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) amd64fre

LAST_CONTROL_TRANSFER:  from fffff8001d714f5c to fffff8001d5c38a0

STACK_TEXT:  
ffffd000`218881c8 fffff800`1d714f5c : 00000000`000000c2 00000000`00000007 00000000`00001200 00000000`00000000 : nt!KeBugCheckEx
ffffd000`218881d0 fffff800`52303653 : 00000000`00000000 ffffe000`049b0500 ffffe000`049a1390 00000000`00000000 : nt!ExDeferredFreePool+0x6ec
ffffd000`218882c0 fffff800`53383455 : 00000000`00000000 fffff800`534fa6fd 00000000`00000000 00000000`00000000 : NETIO!NetioFreeMdl+0x232d3
ffffd000`21888310 fffff800`522d9142 : ffffe000`031e3500 00000000`00000001 00000000`00000000 00000000`00000000 : tcpip!FlpReturnNetBufferListChain+0x8b585
ffffd000`21888360 fffff800`522d53a2 : 00000000`00000000 ffffe000`049b05f0 00000000`00000000 ffffe000`050ee140 : NETIO!NetioDereferenceNetBufferList+0xb2
ffffd000`218883a0 fffff800`532fad53 : 00000000`00000000 ffffd000`21888400 00000000`00000000 00000000`00000000 : NETIO!NetioDereferenceNetBufferListChain+0x2e2
ffffd000`21888440 fffff800`532f9040 : fffff800`5344b180 ffffe000`050ee140 ffffe000`024e0000 ffffe000`024e0000 : tcpip!IppReceiveHeaderBatch+0x323
ffffd000`21888560 fffff800`533edd30 : ffffe000`03488bd0 00000000`00000000 00000000`00000001 00000000`00000000 : tcpip!IppFlcReceivePacketsCore+0x680
ffffd000`218888e0 fffff800`534fa2fd : ffffe000`04ae2902 ffffe000`02375c10 ffffd000`21888bb9 ffffd000`21883000 : tcpip!IppInspectInjectReceive+0x148
ffffd000`21888940 fffff800`1d52ef63 : 00000000`00000000 00000000`00000000 00000000`00000000 fffff800`534fa7c0 : fwpkclnt!FwppInjectionStackCallout+0xe5
ffffd000`218889d0 fffff800`5350b7ae : fffff800`534fa218 ffffd000`21888b40 00000000`00000010 ffffe000`03b32c70 : nt!KeExpandKernelStackAndCalloutInternal+0xf3
ffffd000`21888ac0 fffff800`52d0231c : ffffe000`03b32c70 00000000`00000000 ffffe000`049b0700 ffffe000`02e42650 : fwpkclnt!FwpsInjectTransportReceiveAsync0+0x2ea
ffffd000`21888c00 fffff800`52d026ed : ffffe000`050ee140 ffffe000`02e42650 fffff800`52d06e10 00000000`00000000 : mydriver!WFPCloneReinjectInbound+0x18c
ffffd000`21888c80 fffff800`1d571554 : ffffe000`03b33880 ffffe000`02e42650 00000000`00000080 00000000`00000001 : mydriver!WFP_AuthenticateThread+0x315
ffffd000`21888d40 fffff800`1d5c9ec6 : ffffd000`205ce180 ffffe000`03b33880 ffffd000`205da240 00000000`00005000 : nt!PspSystemThreadStartup+0x58
ffffd000`21888da0 00000000`00000000 : ffffd000`21889000 ffffd000`21883000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

There are some observations which may help:

-> Happens sometimes when we pend packet at ALE AUTH RECIEVE ( INBOUND ) and then process packets in separate thread and then while reinjecting it deferences the NET_BUFFER_LIST.
   Since this happens only sometimes,so when we try to deference BSOD happens.

-> The machine has NSClient++ installed.It is observed that when nscp.exe connects at port 5666 then at server process it is INBOUND at 5666 port and while reinjecting the packet it    dereferences.After uninstalling NSClient++ this problem also happened though very infrequently.

-> I want to know under what conditions does derefernce happens so that I can skip dereference myself later for that particular case.

-> Searching through google I could find many such cases where WFP driver crashes similarly but everywhere the solution is just to uninstall the particular driver.


Windows developer

推荐答案

据我记得你应该在分类回调中引用原来的NBL,

As far as I recall you should reference the original NBL in the classify callback,

然后,您需要克隆原始NBL并注入CLONE并取消引用

then, you need to clone the original NBL and inject the CLONE and dereference

原始NBL。

你这样做了吗?


这篇关于WFP驱动程序BSOD位于FwpsInjectTransportReceiveAsync0的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

08-19 03:17