Синий экран смерти появляется при STOP 0xC2, вызванном тем, что Picadm освобождает область, управляемую кэшированной памятью

Question

Picadm - системный драйвер, написанный нами. Мы включили специальный пул, чтобы синий экран появлялся в точке повреждения.

Синий экран появляется со следующей информацией:

---

• *
• Анализ ошибок *
• *

  ---

BAD_POOL_CALLER (c2) Текущий поток делает неверный запрос пула. Обычно это плохой уровень IRQL или двойное освобождение одного и того же распределения и т. Д. Аргументы: Arg1: 0000000000000007, попытка освободить пул, который уже был освобожден Arg2: 0000000000001097, (зарезервировано) Arg3: 0000000000210007, Содержимое памяти блока пула Arg4: fffff8a004b98e00, адрес освобождаемого блока пула *

Приведенная выше информация показывает, что fffff8a004b98e00 освобождается дважды, что приводит к 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*

Выше показано, что этот адрес удаляется дважды.

Запрос: Мне кажется довольно странным, что обе трассировки стека абсолютно одинаковы. Даже нить такая же. Каковы возможные причины этого. Я проверил код, участвующий в трассировке стека, и не могу найти ни одного оператора while / do / for или jump, приводящего к выполнению CcUninitializeCacheMap дважды.

Ниже представлен стек потоков во время 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

Возврат может вызвать эту проблему.ОС вызывает ваш обработчик более одного раза в разных случаях (я предполагаю, что это часть сценария закрытия файла).Например, вполне возможно, что вы попытаетесь обратиться к уже закрытому обработчику файла для второго вызова - или к какой-либо другой ошибке такого рода.Проверьте управление своими внутренними ресурсами.