问题描述
嗨
我们有一个基于检查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的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！