Announcing Windows 10 Insider Fast+Skip Ahead Build 17040 for PC Insider

Can anybody read into this?

Code:

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: 0000000000000004, Pool header has been corrupted
Arg2: 0000000000000000, Pointer to pool header
Arg3: 0000000000000000, First part of pool header contents
Arg4: ffffd70c73298018, 0

0: kd> k
 # Child-SP          RetAddr           Call Site
00 ffffee81`acf95278 fffff803`54762d7e nt!KeBugCheckEx
01 ffffee81`acf95280 fffff803`54b02213 nt!ExFreePoolWithTag+0x1d4e
02 ffffee81`acf95360 fffff803`549ac8cd nt!MiBuildImageControlArea+0x15565b
03 ffffee81`acf953f0 fffff803`549aad78 nt!MiCreateImageFileMap+0x3d5
04 ffffee81`acf955c0 fffff803`549d782e nt!MiCreateNewSection+0x228
05 ffffee81`acf95730 fffff803`549d6eed nt!MiCreateImageOrDataSection+0x2ce
06 ffffee81`acf95820 fffff803`549d6dc4 nt!MiCreateSection+0xdd
07 ffffee81`acf95980 fffff803`549d6be5 nt!MmCreateSection+0xe4
08 ffffee81`acf95a00 fffff803`5463c253 nt!NtCreateSection+0x155
09 ffffee81`acf95a90 00007ff9`a01fc704 nt!KiSystemServiceCopyEnd+0x13
0a 00000069`f177e9d8 00000000`00000000 0x00007ff9`a01fc704

Anybody realize there's a secret Library called 'Slideshow' in: ?

C:\Users\{your name}\AppData\Local\Microsoft\Windows\BackgroundSlideshow

doriandiaconu said:

Can anybody read into this?

Looks like the memory manager was initially mapping a file into memory (NT calls this a section object), it does this by allocating memory from pools of kernel memory. After that, it attempted to deallocate a block of pool memory with some specific tag (ExFreePoolWithTag). The evidence points towards a double free, in other words the memory manager is trying to free something that is no longer there, which leads to undefined behavior and often a crash.

We see that the pool header and the first parts of the pool header contents are zeroed out. Combine this with the fact that the function that called ExBugCheck (which is the function that creates the blue screen among other things) was an attempt to free a pool allocation, so I think it was likely an attempt to free something that was already freed.

For reference, a pool header is the metadata Windows kernel adds to requests when allocating/deallocating memory from a pool. You can view this data structure in windbg from a live kernel session:

Code:

dt nt!_pool_header
   +0x000 PreviousSize     : Pos 0, 8 Bits
   +0x000 PoolIndex        : Pos 8, 8 Bits
   +0x002 BlockSize        : Pos 0, 8 Bits
   +0x002 PoolType         : Pos 8, 8 Bits
   +0x000 Ulong1           : Uint4B
   +0x004 PoolTag          : Uint4B
   +0x008 ProcessBilled    : Ptr64 _EPROCESS
   +0x008 AllocatorBackTraceIndex : Uint2B
   +0x00a PoolTagHash      : Uint2B

Spectrum said:

Looks like the memory manager was initially mapping a file into memory (NT calls this a section object), it does this by allocating memory from pools of kernel memory. After that, it attempted to deallocate a block of pool memory with some specific tag (ExFreePoolWithTag). The evidence points towards a double free, in other words the memory manager is trying to free something that is no longer there, which leads to undefined behavior and often a crash.

We see that the pool header and the first parts of the pool header contents are zeroed out. Combine this with the fact that the function that called ExBugCheck (which is the function that creates the blue screen among other things) was an attempt to free a pool allocation, so I think it was likely an attempt to free something that was already freed.

For reference, a pool header is the metadata Windows kernel adds to requests when allocating/deallocating memory from a pool. You can view this data structure in windbg from a live kernel session:

Code:

dt nt!_pool_header
   +0x000 PreviousSize     : Pos 0, 8 Bits
   +0x000 PoolIndex        : Pos 8, 8 Bits
   +0x002 BlockSize        : Pos 0, 8 Bits
   +0x002 PoolType         : Pos 8, 8 Bits
   +0x000 Ulong1           : Uint4B
   +0x004 PoolTag          : Uint4B
   +0x008 ProcessBilled    : Ptr64 _EPROCESS
   +0x008 AllocatorBackTraceIndex : Uint2B
   +0x00a PoolTagHash      : Uint2B

Thank you for the comment. Any idea on how to fix this, though?

If that crash is only occurring on a specific insider build, it is likely a fault of that build and not something that can be fixed by someone outside of Microsoft.

Otherwise, I'd suggest you create a post in the BSOD subforum after running the log collection tool. We'd need to see if there is more information about the cause of the bugcheck before we can give much of an answer.