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