BAD_POOL_HEADER (19) and MmAllocateContiguousMemory

NTDEV
1

Hi,

When getting a BAD_POOL_HEADER (19) panic, is it only for memory that was allocated using ExAllocatePoolXXXX or it can be also for memory that was allocated with MmAllocateContiguousMemory ?

To be more specific, assuming there is some code that allocated memory with ExAllocatePoolXXXX and then tried to access it after it was released and corrupted it, this may kill another code trying to use the same memory. Can we get the same effect by using MmAllocateContiguousMemory, freeing it and then trying to access it again ?

Shay

2

> Hi,

When getting a BAD_POOL_HEADER (19) panic, is it only for memory that was
allocated using ExAllocatePoolXXXX or it can be also for memory that was
allocated with MmAllocateContiguousMemory ?

To be more specific, assuming there is some code that allocated memory
with ExAllocatePoolXXXX and then tried to access it after it was released
and corrupted it, this may kill another code trying to use the same
memory. Can we get the same effect by using MmAllocateContiguousMemory,
freeing it and then trying to access it again ?

Your analysis is partly correct. However, note that this error occurs
when the damage is detected, which could be hundreds of trillions of
instructions after the damage was done. Other causes include accidental
use of stale pointers in local variables and hep objects, and buffer
overruns.

Use the Driver Verifier with all memory options turned on to look for the
damage before doing gratuitous rewrites of the code that may only hide the
problem for a while, instead of fixing it. Memory damage bugs are among
the hardest to find, and changing the allocation to a less robust one (the
chances of allocating contiguous memory failing due to lack of resources
are much higher than the ExAllocatePool operations failing) is not the
correct approach.
joe

Shay

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

3

MmAllocateContiguousMemory may satisfy some allocations out of non-paged
pool, so while I’ve never personally caused this issue I would say that it’s
possible.

Of course, if you’re scribbling over an allocation that you’ve previously
freed and it’s causing this bugcheck, then I would say that, yes, it can
definitely cause this issue :slight_smile:

-scott
OSR

“harel, shay” wrote in message news:xxxxx@ntdev…

Hi,

When getting a BAD_POOL_HEADER (19) panic, is it only for memory that was
allocated using ExAllocatePoolXXXX or it can be also for memory that was
allocated with MmAllocateContiguousMemory ?

To be more specific, assuming there is some code that allocated memory with
ExAllocatePoolXXXX and then tried to access it after it was released and
corrupted it, this may kill another code trying to use the same memory. Can
we get the same effect by using MmAllocateContiguousMemory, freeing it and
then trying to access it again ?

Shay

4

My intent was never to try and use different allocation to hide the problem :wink:
The code I suspect is doing two different allocations, I wanted to know in which one to concentrate.

Shay

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Wednesday, December 19, 2012 9:53 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] BAD_POOL_HEADER (19) and MmAllocateContiguousMemory

Hi,

When getting a BAD_POOL_HEADER (19) panic, is it only for memory that
was allocated using ExAllocatePoolXXXX or it can be also for memory
that was allocated with MmAllocateContiguousMemory ?

To be more specific, assuming there is some code that allocated memory
with ExAllocatePoolXXXX and then tried to access it after it was
released and corrupted it, this may kill another code trying to use
the same memory. Can we get the same effect by using
MmAllocateContiguousMemory, freeing it and then trying to access it again ?

Your analysis is partly correct. However, note that this error occurs when the damage is detected, which could be hundreds of trillions of instructions after the damage was done. Other causes include accidental use of stale pointers in local variables and hep objects, and buffer overruns.

Use the Driver Verifier with all memory options turned on to look for the damage before doing gratuitous rewrites of the code that may only hide the problem for a while, instead of fixing it. Memory damage bugs are among the hardest to find, and changing the allocation to a less robust one (the chances of allocating contiguous memory failing due to lack of resources are much higher than the ExAllocatePool operations failing) is not the correct approach.
joe

Shay

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer

NTDEV is sponsored by OSR

For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars

To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer

5

>MmAllocateContiguousMemory may satisfy some allocations out of non-paged

pool, so while I’ve never personally caused this issue I would say that
it’s possible.

Do you have any information that backs this ? Can a call to
MmAllocatePagesForMdl also charge against the pool ?

//Daniel

6

>Do you have any information that backs this ?

Sure. It used to even be mentioned somewhere in the docs I think (though it
doesn’t anymore). Just try calling it a few times with varying sizes and at
different times during boot, you’ll then see different results when you
!pool the return value.

For example, here’s one successful call asking for 64K:

kd> !pool 0x885e1000 2
Pool page 885e1000 region is Nonpaged pool
*885e1000 : large page allocation, Tag is Cont, size is 0x10000 bytes
Pooltag Cont : Contiguous physical memory allocations for device
drivers

And then followed immediately by another successful call asking for 10MB:

kd> !pool 0x8de00000 2
Pool page 8de00000 region is Unknown
8de00000 is not a valid large pool allocation, checking large session
pool…
8de00000 is not a valid small pool allocation, checking large pool…
unable to get pool big page table - either wrong symbols or pool tagging is
disabled
8de00000 is freed (or corrupt) pool
Bad allocation size @8de00000, zero is invalid

***
*** An error (or corruption) in the pool was detected;
*** Pool Region unknown (0xFFFFFFFF8DE00000)
***
*** Use !poolval 8de00000 for more details.
***

kd> !pte 0x8de00000
VA 8de00000
PDE at C0602378 PTE at C046F000
contains 000000002B0FD863 contains 000000007A0AA963
pfn 2b0fd —DA–KWEV pfn 7a0aa -G-DA–KWEV

Note that this experiment was done on Win7, though it looks as though you’ll
get the same type of results on Win8.

Can a call to MmAllocatePagesForMdl also charge against the pool ?

No. I suspect that the expectation there is that you’ll be *optionally*
mapping all or pieces of that memory using System PTEs. No point in wasting
a virtually contiguous chunk of non-paged pool for something that might
never be used.

-scott
OSR

wrote in message news:xxxxx@ntdev…

MmAllocateContiguousMemory may satisfy some allocations out of non-paged
pool, so while I’ve never personally caused this issue I would say that
it’s possible.

Do you have any information that backs this ? Can a call to
MmAllocatePagesForMdl also charge against the pool ?

//Daniel

7

Another way a driver could trigger this is by writing beyond the end of his contiguous allocation. If the allocation size is not a multiple of page size, and the allocation was satisfied from the nonpaged pool, the remainder of the last page may be used for other small pool allocations.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Scott Noone
Sent: Wednesday, December 19, 2012 6:56 AM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] BAD_POOL_HEADER (19) and MmAllocateContiguousMemory

MmAllocateContiguousMemory may satisfy some allocations out of non-paged pool, so while I’ve never personally caused this issue I would say that it’s possible.

Of course, if you’re scribbling over an allocation that you’ve previously freed and it’s causing this bugcheck, then I would say that, yes, it can definitely cause this issue :slight_smile:

-scott
OSR

“harel, shay” wrote in message news:xxxxx@ntdev…

Hi,

When getting a BAD_POOL_HEADER (19) panic, is it only for memory that was allocated using ExAllocatePoolXXXX or it can be also for memory that was allocated with MmAllocateContiguousMemory ?

To be more specific, assuming there is some code that allocated memory with ExAllocatePoolXXXX and then tried to access it after it was released and corrupted it, this may kill another code trying to use the same memory. Can we get the same effect by using MmAllocateContiguousMemory, freeing it and then trying to access it again ?