ExAllocatePoolWithTag returning invalid paged pool

Aditya_Shrivastava · December 16, 2011, 11:33am

Hi,

In my DriverEntry, I am observing a crash when I pass the pointer returned from ExAllocatePoolWithTag. When I inspect the pointer this is what I observed.

The call is

dataBuffer = ExAllocatePoolWithTag( PagedPool, size, ‘ABCD’ ); //where size is 0xb7ae38

=======================================
kd> dc dataBuffer
bad0bbf0 e2800000 00200382 bad0bc64 b92a590e … .d…Y*.

kd> !pool 0xe2800000
Pool page e2800000 region is Paged pool
e2800000 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
e2800000 is freed (or corrupt) pool
Bad allocation size @e2800000, too large

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

Pool page [e2800000] is __inVALID.

Analyzing linked list…

Scanning for single bit errors…

None found
==================end=====================

It clearly says that “Bad allocation size @e2800000, too large”; so I reduced it to 0xAE38, 0x8000, 0x4000; all fails but does return some not-null value; (small sizes go fine 0x200, 0x400.)

Now the query is why it does not return NULL? As per docs; it should.

Any corner case which I am hitting? The OS is XP SP3.

Thanks
Aditya

Doron_Holan · December 16, 2011, 11:54am

What happens when you deref the pointer and read/write from/to it? Perhaps the debugger extension isn’t working and the alloc is valid

d

debt from my phone

From: xxxxx@gmail.com
Sent: 12/16/2011 8:34 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] ExAllocatePoolWithTag returning invalid paged pool

Hi,

In my DriverEntry, I am observing a crash when I pass the pointer returned from ExAllocatePoolWithTag. When I inspect the pointer this is what I observed.

The call is

dataBuffer = ExAllocatePoolWithTag( PagedPool, size, ‘ABCD’ ); //where size is 0xb7ae38

=======================================
kd> dc dataBuffer
bad0bbf0 e2800000 00200382 bad0bc64 b92a590e … .d…Y*.

kd> !pool 0xe2800000
Pool page e2800000 region is Paged pool
e2800000 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
e2800000 is freed (or corrupt) pool
Bad allocation size @e2800000, too large

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

Pool page [e2800000] is __inVALID.

Analyzing linked list…

Scanning for single bit errors…

None found
==================end=====================

It clearly says that “Bad allocation size @e2800000, too large”; so I reduced it to 0xAE38, 0x8000, 0x4000; all fails but does return some not-null value; (small sizes go fine 0x200, 0x400.)

Now the query is why it does not return NULL? As per docs; it should.

Any corner case which I am hitting? The OS is XP SP3.

Thanks
Aditya

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

OSR_Community_User · December 16, 2011, 12:46pm

That clause about “either wrong sybmols…” Can you demonstrate that you
have the correct symbols loaded?

I find that having the wrong symbols loaded is one of the most common
problems people encounter while debugging.
joe

Hi,

In my DriverEntry, I am observing a crash when I pass the pointer returned
from ExAllocatePoolWithTag. When I inspect the pointer this is what I
observed.

The call is

dataBuffer = ExAllocatePoolWithTag( PagedPool, size, ‘ABCD’ ); //where
size is 0xb7ae38

=======================================
kd> dc dataBuffer
bad0bbf0 e2800000 00200382 bad0bc64 b92a590e … .d…Y*.

kd> !pool 0xe2800000
Pool page e2800000 region is Paged pool
e2800000 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
e2800000 is freed (or corrupt) pool
Bad allocation size @e2800000, too large

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

Pool page [e2800000] is __inVALID.

Analyzing linked list…

Scanning for single bit errors…

None found
==================end=====================

It clearly says that “Bad allocation size @e2800000, too large”; so I
reduced it to 0xAE38, 0x8000, 0x4000; all fails but does return some
not-null value; (small sizes go fine 0x200, 0x400.)

Now the query is why it does not return NULL? As per docs; it should.

Any corner case which I am hitting? The OS is XP SP3.

Thanks
Aditya

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

Pavel_Lebedinsky · December 16, 2011, 1:27pm

It’s more likely the other clause (pool tagging disabled). Since this is XP, you need to enable pool tagging using gflags to force the system to allocate tracking tables for big (> 4K) allocations.

Do “x nt!PoolBigPageTable”, it will probably show that the table is NULL.

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@flounder.com
Sent: Friday, December 16, 2011 9:46 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] ExAllocatePoolWithTag returning invalid paged pool

That clause about “either wrong sybmols…” Can you demonstrate that you have the correct symbols loaded?

I find that having the wrong symbols loaded is one of the most common problems people encounter while debugging.
joe

In my DriverEntry, I am observing a crash when I pass the pointer
returned from ExAllocatePoolWithTag. When I inspect the pointer this
is what I observed.

kd> !pool 0xe2800000
Pool page e2800000 region is Paged pool
e2800000 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

Aditya_Shrivastava · December 16, 2011, 11:40pm

>>Can you demonstrate that you have the correct symbols loaded?

I definitely have correct symbols loaded, did not bother mentioning that as that was quite obvious.

>What happens when you deref the pointer and read/write from/to it? Perhaps the debugger extension isn’t working and the alloc is valid

As I said; it crashed when I passed it to API (ZwReadFile); which makes me debug it at first place.

@Pavel

Thanks, will check that and update here.

Thanks for all the inputs

Aditya_Shrivastava · December 17, 2011, 3:33am

Argh, yeah that did it. Windbg was interpreting it incorrectly unless I enabled pool tagging.

I checked again and the crash was on another pointer altogether (and was a real easy one to fix). It was my guilt of using such big buffer at kernel that I instantly checked this buffer first; windbg did not have proper input to show correct information and I post it all here.

My bad. Sorry