- ExAllocatePoolWithTag / ExFreePoolWithTag failure
- Posted by Jan on October 29th, 2007
Greetings,
I am currently looking at some code that makes a successful call to
ExAllocatePoolWithTag(). It is asking for NonPagedPool, and the function
returns with a valid pointer (e.g. it is not null). The IRQL <=
DISPATCH_LEVEL.
Immediately following this call, I can make a call to the comparable Free
function call, and get the BSOD (BAD_POOL_CALLER), with an error code of 41:
The current thread attempted to free a non-allocated nonpaged pool address.
Since the Allocate did not return with a NULL pointer, and the IRQL seems to
be at the right spot, can anyone give me a suggestion on what else to look at?
Thanks,
Jan
- Posted by Gianluca Varenni on October 29th, 2007
Can you post the code snippet?
The only reason I can think of is some bad memory corruption that triggers
the bug check only upon freeing your chunk of memory.
Have a nice day
GV
--
Gianluca Varenni, Windows DDK MVP
CACE Technologies
http://www.cacetech.com
"Jan" <Jan@discussions.microsoft.com> wrote in message
news:495A47DE-AD18-41D8-9222-4806769A586A@microsoft.com...
- Posted by John Hensley on October 29th, 2007
This will happen if the tag you pass to ExFreePoolWithTag() is not the same
one that was passed to ExAllocatePoolWithTag(). If you can call ExFreePool()
on the pointer returned by ExAllocatePoolWithTag() without getting the BSOD
it points to a mismatched tag.
--
John Hensley
www.resqware.com
"Jan" wrote:
- Posted by Don Burn on October 29th, 2007
This is incorrect, the tags are only checked this way if you use the
PROTECTED_POOL flag (high order bit of the word) on the tag. Secondly, the
tag mismatch is not code 0x41
--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
Website: http://www.windrvr.com
Blog: http://msmvps.com/blogs/WinDrvr
Remove StopSpam to reply
"John Hensley" <resqware@discussions.microsoft.com> wrote in message
news:C641B8B6-C3FB-4A3E-B898-D888A205E5CE@microsoft.com...
- Posted by Jan on October 30th, 2007
I now suspect that the actual call to the ExAllocPoolWithTag() is working
correctly. The call looks like this:
dxSave->SaveLocalBuffer = ExAllocatePoolWithTag( NonPagedPool, CurSize[i]
<< 1, 1 );
I was erroneous in stating I couldn't do them back-to-back. When I do the
Free right after the Allocate:
ExFreePoolWithTag( dxSave->SaveLocalBuffer, 1 );
It works properly. It is when the ExFreePoolWithTag gets called elsewhere,
it fails. I now think it is in this driver code, and not in how the calls
are made, as mentioned before.
Thanks for your time. When I determine why this is happening, I will follow
up with what caused it.
Cheers,
Jan
"Gianluca Varenni" wrote:
- Posted by Peter Wieland [MSFT] on November 2nd, 2007
is the issue reproducible?
Are you literally freeing the memory after allocating it? Or do you do a
little bit of work in between? If you're really calling it immediately
afterwards then one possibility is that the pool was already corrupted in a
way which ExAllocatePoolWithTag didn't spot but ExFreePool did.
Have you tried turning on the driver verifier and special pool and seeing if
that points out anything suspicious?
-p
--
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jan" <Jan@discussions.microsoft.com> wrote in message
news:495A47DE-AD18-41D8-9222-4806769A586A@microsoft.com...