Is there any way to locate pool memory (with a known 4 char tag allocated with ExAllocatePoolWithTag) when tagging was disabled at the time the crash dump was made?
This memory happens to be in the “Large Pool” but since tagging was disabled there appears to be no Large Pool Allocation Table (makes sense). As part of the ‘Large Pool’ it seems that each allocation is not tagged individually with the four character tag so I cannot just search for that in the dump (also makes sense). I can make a new crashdump with tagging enabled and find what Im looking for in WinDbg, but I need to use the crashdump that was made with the tagging disabled. Is there any way to do this? If tags are ignored what differentiates all of the pool allocations from one another?
" If tags are ignored what differentiates all of the pool allocations from one another?"
Nothing. Note that on w2k3 and later tags are always enabled. There are always pool allocation tables, regardless of tags being enabled or disabled.
If you are looking for a specific type of object allocated from pool, if there is some identifiable signature in that object, such as a size value etc. search for that. I generally define data structures to contain identifiable signatures just so they can be located in a dump file.
Yes, I am aware that w2k3 and later has tagging enabled by default. I should have specified that the dump I am working with was made on an XP pro system with tagging disabled.
You said, “There are always pool allocation tables, regardless of tags being enabled or disabled.”
Was this in reference to w2k3 only or to all systems? If this includes all systems, where would I find the table in the crash dump? When tagging is enabled I found what looks to be the large pool allocation table consisting of Virtual Memory offset to pool data (4B) followed by tag (4B) followed by size (2B). With tagging turned off presumably this table would have the same information without the 4 char tag? Is windows smart enough to shrink the table size or are the 4 characters zeroed out? Any guidance would be really helpful.
The pool header structure is the same if tag tracking is enabled or disabled. As far as I can tell your tag entry is also always applied to your allocation’s pool header regardless of pool tag tracking being enabled or disabled. The enable pool tags flag does not turn on or off the action of putting a tag into the pool header, it turns on or off tracking allocations by pool tag. If the data structure changed you would need a recompiled os.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:bounce-274284- xxxxx@lists.osr.com] On Behalf Of xxxxx@yahoo.com
Sent: Friday, December 29, 2006 11:48 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Locate Pool Memory Without Tagging
Thank you for the quick response.
Yes, I am aware that w2k3 and later has tagging enabled by default. I
should have specified that the dump I am working with was made on an XP
pro system with tagging disabled.
You said, “There are always pool allocation tables, regardless of tags
being enabled or disabled.”
Was this in reference to w2k3 only or to all systems? If this includes
all systems, where would I find the table in the crash dump? When
tagging is enabled I found what looks to be the large pool allocation
table consisting of Virtual Memory offset to pool data (4B) followed by
tag (4B) followed by size (2B). With tagging turned off presumably this
table would have the same information without the 4 char tag? Is
windows smart enough to shrink the table size or are the 4 characters
zeroed out? Any guidance would be really helpful.
“The pool header structure is the same if tag tracking is enabled or disabled…The enable pool tags flag does not turn on or off the action of putting a tag into the pool header”
I agree this appears to be the case for regular pool allocations where the header (including the tag) is stored just before the corresponding data. Larger pool allocations such as the one I am dealing with seem to be handled differently. I should have been more clear in message 3 that I am primarily concerned with looking at large pool allocations, not regular ones. There is a “Large Pool Allocation Table” that stores the tag, VM offset to the pool data, and size of pool for each large pool allocation. The output of !poolfind indicates that these larger pool allocations are handled in this way. Basically, the pool header is stored separately from the pool data above some size (maybe a page?). When tagging is disabled, this “Large Pool Allocation Table” does not seem to exist in the crash dump (not sure why based on your previous post), so I have no way to find the offsets to the “large pool” data to examine them. I have found very little discussing large pools and the allocation table so any information on how it works would be helpful.