Comments on: Crash Dump Analysis Patterns (Part 23b)

By: Dmitry Vostokov

Dmitry Vostokov — Mon, 04 Jan 2016 22:59:00 +0000

DRIVER_PAGE_FAULT_IN_FREED_SPECIAL_POOL (d5)
Memory was referenced after it was freed.
This cannot be protected by try-except.
When possible, the guilty driver’s name (Unicode string) is printed on
the bugcheck screen and saved in KiBugCheckDriver.

By: Dmitry Vostokov

Dmitry Vostokov — Fri, 30 Nov 2012 16:18:28 +0000

If you see some leaking pool tag you can find its entries using this command !poolfind ABCD and dump their memory

By: Dmitry Vostokov

Dmitry Vostokov — Fri, 30 Nov 2012 16:14:56 +0000

Recentlyh found that search needs to be done without h prefix:
findstr /m /l ABCD

By: Sinni

Sinni — Mon, 27 Feb 2012 22:13:55 +0000

In my case, special pool is enabled and it shows both the free happening through same thread, interestingly, both the stacks are exactly same.

2: kd> .bugcheck
Bugcheck code 000000C2
Arguments 00000000`00000007 00000000`00001097 00000000`00210007 fffff8a0`04b98e00
2: kd> !pool fffff8a0`04b98e00 2
Pool page fffff8a004b98e00 region is Paged pool
*fffff8a004b98df0 size: 210 previous size: 70 (Free) *MmSt
Pooltag MmSt : Mm section object prototype ptes, Binary : nt!mm
2: kd> !verifier 0×80 fffff8a0`04b98e00

Log of recent kernel pool Allocate and Free operations:

There are up to 0×10000 entries in the log.

Parsing 0×0000000000010000 log entries, searching for address 0xfffff8a004b98e00.

=================================
Pool block fffff8a004b98df0, Size 0000000000000210, Thread fffffa80122674f0
fffff80001b0bc9a nt!VfFreePoolNotification+0×4a
fffff800017a367c nt!ExDeferredFreePool+0×126d
fffff8000165b880 nt!MiDeleteSegmentPages+0×35c
fffff8000195cf2f nt!MiSegmentDelete+0×7b
fffff80001637e07 nt!MiCleanSection+0×2f7
fffff80001676754 nt!ObfDereferenceObject+0xd4
fffff80001661170 nt!CcDeleteSharedCacheMap+0×1bc
fffff80001699880 nt!CcUninitializeCacheMap+0×2f0
fffff880030ecfa6 picadm!OwCommonCleanup+0×4b6
fffff880030ec840 picadm!FsdCleanup+0×2a8
fffff880030ec994 picadm!OwFsdCleanup+0×38
fffff80001b16750 nt!IovCallDriver+0xa0
fffff800019824bf nt!IopCloseFile+0×11f
=================================
Pool block fffff8a004b98df0, Size 0000000000000210, Thread fffffa80122674f0
fffff80001b0bc9a nt!VfFreePoolNotification+0×4a
fffff800017a367c nt!ExDeferredFreePool+0×126d
fffff8000165b880 nt!MiDeleteSegmentPages+0×35c
fffff8000195cf2f nt!MiSegmentDelete+0×7b
fffff80001637e07 nt!MiCleanSection+0×2f7
fffff80001676754 nt!ObfDereferenceObject+0xd4
fffff80001661170 nt!CcDeleteSharedCacheMap+0×1bc
fffff80001699880 nt!CcUninitializeCacheMap+0×2f0
fffff880030ecfa6 picadm!OwCommonCleanup+0×4b6
fffff880030ec840 picadm!FsdCleanup+0×2a8
fffff880030ec994 picadm!OwFsdCleanup+0×38
fffff80001b16750 nt!IovCallDriver+0xa0
fffff800019824bf nt!IopCloseFile+0×11f

But current thread has no sign of this driver : picadm.sys. It is something like this:

2: kd> k
Child-SP RetAddr Call Site
fffff880`02378b28 fffff800`017a360e nt!KeBugCheckEx
fffff880`02378b30 fffff800`0178a53e nt!ExDeferredFreePool+0×11eb
fffff880`02378be0 fffff800`01798a0a nt!MiDeleteCachedSubsection+0×10ae
fffff880`02378c90 fffff800`01798b43 nt!MiRemoveUnusedSegments+0×8a
fffff880`02378cc0 fffff800`01910726 nt!MiDereferenceSegmentThread+0×103
fffff880`02378d40 fffff800`0164fae6 nt!PspSystemThreadStartup+0×5a
fffff880`02378d80 00000000`00000000 nt!KiStartSystemThread+0×16

Please suggest!

By: Crash Dump Analysis » Blog Archive » Insufficient memory, handle leak, wait chain, deadlock, inconsistent dump and overaged system: pattern cooperation

Fri, 13 Aug 2010 19:13:18 +0000

[…] However we see that drivers using AAAA and BBBB consumed almost 65Mb and we can search for them as described here. […]

By: Crash Dump Analysis » Blog Archive » Icons for Memory Dump Analysis Patterns (Part 42)

Wed, 19 May 2010 11:44:26 +0000

[…] we introduce an icon for Double Free (kernel pool) […]

By: Dmitry Vostokov

Dmitry Vostokov — Thu, 17 Apr 2008 10:48:04 +0000

a4ef7890 size: 88 previous size: 88 (Allocated) NEtd
a4ef7918 is not a valid large pool allocation, checking large session pool…

a4ef7890+88 = a4ef7918

I would try to see its contents, perhaps dds and dps would point to some symbolic data. Also search for this address in kernel space might point to some other blocks as well.

If you suspect some driver you might want to enable driver verifier special pool

By: Bill

Bill — Wed, 09 Apr 2008 15:42:51 +0000

What happens if the block being deallocated can’t be analyzed:

4: kd> !pool a4ef7920
Pool page a4ef7920 region is Nonpaged pool
a4ef7000 size: e0 previous size: 0 (Allocated) MmCi
a4ef70e0 size: 68 previous size: e0 (Allocated) TCIZ
a4ef7148 size: e0 previous size: 68 (Allocated) MmCi
a4ef7228 size: 98 previous size: e0 (Allocated) File (Protected)
a4ef72c0 size: 98 previous size: 98 (Allocated) File (Protected)
a4ef7358 size: 100 previous size: 98 (Allocated) MmCi
a4ef7458 size: 28 previous size: 100 (Allocated) NtFs
a4ef7480 size: 40 previous size: 28 (Allocated) Ntfr
a4ef74c0 size: 98 previous size: 40 (Allocated) File (Protected)
a4ef7558 size: 8 previous size: 98 (Free) CcPL
a4ef7560 size: 40 previous size: 8 (Allocated) SevE
a4ef75a0 size: 40 previous size: 40 (Allocated) Ntfr
a4ef75e0 size: 10 previous size: 40 (Free) TCI1
a4ef75f0 size: 180 previous size: 10 (Allocated) MmCi
a4ef7770 size: 98 previous size: 180 (Allocated) File (Protected)
a4ef7808 size: 88 previous size: 98 (Allocated) Adap (Protected)
a4ef7890 size: 88 previous size: 88 (Allocated) NEtd
a4ef7918 is not a valid large pool allocation, checking large session pool…
a4ef7918 is freed (or corrupt) pool
Bad allocation size @a4ef7918, zero is invalid

***
*** An error (or corruption) in the pool was detected;
*** Attempting to diagnose the problem.
***
*** Use !poolval a4ef7000 for more details.
***

Pool page [ a4ef7000 ] is __inVALID.

Analyzing linked list…
[ a4ef7890 –> a4ef7a10 (size = 0×180 bytes)]: Corrupt region

Scanning for single bit errors…

None found