I have a kernel buffer, and I need to determine what is the pool tag assosicated with its pool, and also what is the pool’s start address. How can I achieve this?
Poolfind and Poolused both take a tag as input, but I want that as an output.
!pool
1 Like
@Dejan_Maksimovic said:
!pool
When I use this on an address within any driver, I get this:
!pool 0xfffff8032ba01087
Pool page fffff8032ba01087 region is Unknown
fffff8032ba01000 is not a valid large pool allocation, checking large session pool...
Unable to read large session pool table (Session data is not present in mini and kernel-only dumps)
fffff8032ba01000 is not valid pool. Checking for freed (or corrupt) pool
Address fffff8032ba01000 could not be read. It may be a freed, invalid or paged out page
So it seems like Microsoft doesn’t allocate driver content buffers from pools? In that case, Where does it allocate the buffer from then? Meaning, what type of “Buffer” Is this then if it’s not a from a pool?
When you said “content”, did you mean “context”? They’re certainly allocated from a pool, but it may not be a tagged pool. And as it says, there’s not enough info in your kernel-only dump to tell.
Does the odd number ending of the address not tell you something is wrong
with the pointer?
While !pool can work on that, I am first always suspicious of a memory
corruption if my pointer is not allocation-aligned (2 * sizeof(PVOID)).
So when I use this on a address within any driver, I get this:
@Tim_Roberts said:
When you said “content”, did you mean “context”? They’re certainly allocated from a pool, but it may not be a tagged pool. And as it says, there’s not enough info in your kernel-only dump to tell.
Its a live debugging, I’m basically trying to find a way to tell whether a kernel buffer/pool is a mapped driver file that was loaded by the kernel or not.
Was hoping I can tell it using a pool tag, but it seems like they are either not allocated with a tag, or they belong to a special kernel “buffer” and are not pools at all?
So is there anyway I can tell whether an address belongs to the mapped driver buffer that the kernel allocates when loading drivers? (Note that I’m not talking about the pools that the driver itself is allocating, but the buffer that the kernel allocates when loading drivers)
@Dejan_Maksimovic said:
Does the odd number ending of the address not tell you something is wrong
with the pointer?While !pool can work on that, I am first always suspicious of a memory
corruption if my pointer is not allocation-aligned (2 * sizeof(PVOID)).So when I use this on a address within any driver, I get this:
This is just an address of a instruction inside a driver, as I explained in the above message, I am just trying to tell whether an address belongs to the mapped driver buffer that the kernel allocates when loading drivers or not?
I know that kernel pools also have headers as well, so If drivers are allocated from the normal kernel pool, can I somehow use the header of the pool to determine if an address/buffer/pool belongs is a buffer that windows kernel allocated when loading a driver or not?
On 2023-03-10 8:50 a.m., brad_H wrote:
This is just an address of a instruction inside a driver, as I
explained in the above message, I am just trying to tell whether an
address belongs to the mapped driver buffer that the kernel allocates
when loading drivers or not?
This thread started off asking about a pool start address of a kernel
buffer, but above says address of instruction inside a driver.
If we’re talking about the latter then you can manually list modules
lm and find what module range contains the address, or way more simply
locate nearest ‘ln’ and it will identify the nearest symbol and module.
But that is quite simple so it seems there’s some other nuance you’re
looking for.
-Nathan
!pool works for pool but not everything is pool. !address is what you want here:
0: kd> !address fffff800`47897d50
Usage: Module
Base Address: fffff800`477c0000
End Address: fffff800`47af6000
Region Size: 00000000`00336000
VA Type: BootLoaded
Module name: Ntfs.sys
Module path: [\SystemRoot\System32\Drivers\Ntfs.sys]