picadmがキャッシュメモリ管理領域を解放することにより、ブルースクリーンがSTOP 0xC2で表示される

Question

Picadmは私たちによって書かれたシステムドライバです。私たちは特別なプールを有効にして、ブルースクリーンが破損の時点で発生することを確認しました。

ブルースクリーンは、次の情報で発生：

---

• *
• バグチェック分析*
• *

  ---

BAD_POOL_CALLER（C2） 現在のスレッドを作っています不良プールリクエスト。通常、これは不適切なIRQLレベルまたは同じ割り当てなどを解放するダブルです。 Arg3500000000000007、Arg1：プールブロック Arg4：fffff8a004b98e00、割り当て解除されるプールブロックのアドレス*

上記の情報は、fffff8a004b98e00が2回解放されてBSODになることを示しています。特別なプールが有効になっているので、割り当てをチェックしてこのメ​​モリアドレスの履歴を解放することができます。以下の結果が得られます。

*2: kd> !verifier 0x80 fffff8a0`04b98e00 
Log of recent kernel pool Allocate and Free operations: 
There are up to 0x10000 entries in the log. 
Parsing 0x0000000000010000 log entries, searching for address 0xfffff8a004b98e00. 
====================================================================== 
Pool block fffff8a004b98df0, Size 0000000000000210, Thread fffffa80122674f0 
fffff80001b0bc9a nt!VfFreePoolNotification+0x4a 
fffff800017a367c nt!ExDeferredFreePool+0x126d 
fffff8000165b880 nt!MiDeleteSegmentPages+0x35c 
fffff8000195cf2f nt!MiSegmentDelete+0x7b 
fffff80001637e07 nt!MiCleanSection+0x2f7 
fffff80001676754 nt!ObfDereferenceObject+0xd4 
fffff80001661170 nt!CcDeleteSharedCacheMap+0x1bc 
fffff80001699880 nt!CcUninitializeCacheMap+0x2f0 
fffff880030ecfa6 picadm!OwCommonCleanup+0x4b6 
fffff880030ec840 picadm!FsdCleanup+0x2a8 
fffff880030ec994 picadm!OwFsdCleanup+0x38 
fffff80001b16750 nt!IovCallDriver+0xa0 
fffff800019824bf nt!IopCloseFile+0x11f 
====================================================================== 
Pool block fffff8a004b98df0, Size 0000000000000210, Thread fffffa80122674f0 
fffff80001b0bc9a nt!VfFreePoolNotification+0x4a 
fffff800017a367c nt!ExDeferredFreePool+0x126d 
fffff8000165b880 nt!MiDeleteSegmentPages+0x35c 
fffff8000195cf2f nt!MiSegmentDelete+0x7b 
fffff80001637e07 nt!MiCleanSection+0x2f7 
fffff80001676754 nt!ObfDereferenceObject+0xd4 
fffff80001661170 nt!CcDeleteSharedCacheMap+0x1bc 
fffff80001699880 nt!**CcUninitializeCacheMap**+0x2f0 
fffff880030ecfa6 picadm!OwCommonCleanup+0x4b6 
fffff880030ec840 picadm!FsdCleanup+0x2a8 
fffff880030ec994 picadm!OwFsdCleanup+0x38 
fffff80001b16750 nt!IovCallDriver+0xa0 
fffff800019824bf nt!IopCloseFile+0x11f* 

上記は、このアドレスが2回削除されることを示しています。

クエリ：両方のスタックトレースがまったく同じであることは私には非常に奇妙に思えます。糸も同じです。この事態が起こりうる理由は何か。私は、スタックトレースに含まれるコードをチェックし、CcUninitializeCacheMapの実行に至る間、/ do/forまたはjumpステートメントを見つけることができません。

以下は、BSODが発生した時点のスレッドスタックです。これは、削除が発生した場所と同じスレッドです：

*2: kd> !thread fffffa80122674f0 7 
THREAD fffffa80122674f0 Cid 3de4.41b8 Teb: 000007fffffac000 Win32Thread: fffff900c0ad4850 RUNNING on processor 3 
IRP List: 
    fffffa800a3f1240: (0006,0118) Flags: 00000404 Mdl: 00000000 
Not impersonating 
DeviceMap     fffff8a00fce5bc0 
Owning Process   fffffa8015ca0060  Image:   mstsc.exe 
Attached Process   N/A   Image:   N/A 
Wait Start TickCount  104601006  Ticks: 0 
Context Switch Count  27964     LargeStack 
UserTime     00:00:01.375 
KernelTime    00:00:07.015 
Win32 Start Address 0x000007feef84af90 
Stack Init fffff8801406edb0 Current fffff8801406e300 
Base fffff8801406f000 Limit fffff88014066000 Call 0 
Priority 13 BasePriority 10 UnusualBoost 1 ForegroundBoost 0 IoPriority 2 PagePriority 5 
Child-SP   RetAddr   : Args to Child               : Call Site 
fffff880`1406e3d0 fffff880`0312a75a : 00ffffff`00100011 00000000`0000002b fffff880`03166f88 fffff880`0313000e : picadm!CDF_TraceRoutine+0x401 [p:\src\ica\hostcore\workstation\picadm\win64\retail\obj\pdm.tmh @ 4193] 
fffff880`1406e530 fffff880`03146d9e : 00ffffff`00100011 00000000`0000000e fffff880`03166f88 fffff880`031590a0 : picadm!WPP_SF_sq+0xba [p:\src\ica\hostcore\workstation\picadm\win64\retail\obj\directory.tmh @ 837] 
fffff880`1406e5a0 fffff880`0313674d : fffff980`3a7ecec0 00000000`00000017 fffff880`03166d50 fffff880`031587b0 : picadm!PdmObjectWriteLock+0x6e [p:\src\ica\hostcore\workstation\picadm\pdmobject.cpp @ 175] 
fffff880`1406e5f0 fffff880`0313e968 : fffff980`3a7ecec0 00000000`00076615 fffff880`03166f30 fffff880`03158b30 : picadm!NodeReleaseShare+0xcd [p:\src\ica\hostcore\workstation\picadm\node.cpp @ 529] 
fffff880`1406e650 fffff880`03101f56 : 00000000`00076615 00000000`00000001 fffff980`bf03cf50 fffff880`0311f0cd : picadm!PdmFsdRemoveShareAccess+0x128 [p:\src\ica\hostcore\workstation\picadm\pdm.cpp @ 3541] 
fffff880`1406e6b0 fffff880`030e6943 : 00000000`00000000 fffff980`c3fe4f30 00000000`00000000 00000000`00000001 : picadm!OwRemoveShareAccessFsd+0xfe [h:\devtrees\fsdk_osr\fsdksrc\v1\src\wrapper\fsdsup.cpp @ 4729] 
fffff880`1406e760 fffff880`030ed373 : 00000000`00000004 00000000`00000000 00000000`00000004 00000000`00000000 : picadm!OwRemoveShareAccess+0xf7 [h:\devtrees\fsdk_osr\fsdksrc\v1\src\wrapper\misc.cpp @ 1985] 
fffff880`1406e7f0 fffff880`030ec840 : 00000000`00000000 00000000`00000000 fffffa80`15ca0060 fffff880`03175e00 : picadm!OwCommonCleanup+0x883 [h:\devtrees\fsdk_osr\fsdksrc\v1\src\wrapper\cleanup.cpp @ 1294] 
fffff880`1406e8e0 fffff880`030ec994 : 00000000`b1040100 fffff980`c3fe4f30 fffffa80`057c3e40 fffff880`1406e9e8 : picadm!FsdCleanup+0x2a8 [h:\devtrees\fsdk_osr\fsdksrc\v1\src\wrapper\cleanup.cpp @ 255] 
fffff880`1406e9a0 fffff800`01b16750 : fffffa80`0a3f1240 00000000`00000000 fffffa80`057c3e01 fffff980`33124fc0 : picadm!OwFsdCleanup+0x38 [h:\devtrees\fsdk_osr\fsdksrc\v1\src\wrapper\cleanup.cpp @ 364] 
fffff880`1406e9d0 fffff800`019824bf : fffffa80`0a3f1240 fffffa80`15ca0060 00000000`00000000 fffffa80`07419090 : nt!IovCallDriver+0xa0 
fffff880`1406ea30 fffff800`01968384 : 00000000`00000000 fffffa80`15ca0060 fffff880`1406eae0 00000000`00000018 : nt!IopCloseFile+0x11f 
fffff880`1406eac0 fffff800`01981fb1 : fffffa80`15ca0060 fffffa80`00000001 fffff8a0`11e650d0 00000000`00000000 : nt!ObpDecrementHandleCount+0xb4 
fffff880`1406eb40 fffff800`01981ec4 : 00000000`00000570 fffffa80`15ca0060 fffff8a0`11e650d0 00000000`00000570 : nt!ObpCloseHandleTableEntry+0xb1 
fffff880`1406ebd0 fffff800`016707d3 : fffffa80`122674f0 fffff880`1406eca0 00000000`063d7240 00000000`00000000 : nt!ObpCloseHandle+0x94 
fffff880`1406ec20 00000000`7764f7aa : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13 (TrapFrame @ fffff880`1406ec20) 
00000000`0483eab8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x7764f7aa* 

ご協力いただきありがとうございます！

Answer 1

リエントラントでこの問題が発生する可能性があります。 OSは異なる機会に複数回あなたのハンドラを呼び出します（私はそれがファイル終了シナリオの一部であると仮定します）。たとえば、2番目の呼び出しのために既に閉じられているファイルハンドラ、またはその種の他のバグを参照しようとする可能性は非常に高いです。内部リソース管理を確認してください。