Process memory
Author
Hey guys,
Would any of you happen to know how to determine the owner of a given process address range?
Just for fun I'm working on a process memory dumper, and I want to exclude the memory belonging to mapped DLLs etc. Many debuggers are able to tell you that "calc.exe owns this chunk of memory" and "kernel32.dll owns this chunk of memory".
I've searched on google to no avail, so it'd be great if someone had any information on this subject to share.
Thanks in advance
As far as I know, Windows offers no way of retroactively determining the owning module of an arbitrary memory location, perhaps because of the confusion this would cause regarding memory-mapped files and shared heaps.
If you have an address you know to reside inside the module itself (in particular, a function pointer, initialised constant, embedded resource or stack variable) then you could use VirtualQuery to find the base of that module, then GetModuleBaseName.
But when heaps are thrown into the mix - which don't reside in contiguously with the creating module - you'll have to work harder.
The debuggers and process spies you speak of will tend to enumerate the process's entire committed address-space and work backwards from there. If this is your idea of fun, you'll find PSAPI an invaluable library. Of particular interest are GetModuleInformation and
EnumProcessModules, in addition to those already mentioned. If you are working with external processes, you'll need to use the extended versions of some of these functions.
Admiral
If you have an address you know to reside inside the module itself (in particular, a function pointer, initialised constant, embedded resource or stack variable) then you could use VirtualQuery to find the base of that module, then GetModuleBaseName.
But when heaps are thrown into the mix - which don't reside in contiguously with the creating module - you'll have to work harder.
The debuggers and process spies you speak of will tend to enumerate the process's entire committed address-space and work backwards from there. If this is your idea of fun, you'll find PSAPI an invaluable library. Of particular interest are GetModuleInformation and
EnumProcessModules, in addition to those already mentioned. If you are working with external processes, you'll need to use the extended versions of some of these functions.
Admiral
Author
Thanks for your reply, I'm going to look at the functions you mentioned :D
I'm just about to try using Module32First and Module32Next.
I'm just about to try using Module32First and Module32Next.
If dependency walker is to be trusted, debuggers tend to use the DbgHelp API rather than the PSAPI. Ex: for things like determining the module for walking the call stack, debuggers also tend to use functions like SymGetLineFromAddr()/SymGetLineFromAddr64() or for general module enumeration EnumerateLoadedModules()/EnumerateLoadedModules64().
Author
Well Module32First and Module32Next did the job. They give me the names of the modules along with their base addresses and size. It's up to me to compare each base address with the list I already have, and then I determine how many regions it uses by adding the size to the base address.
I'm guessing that it's safe to assume that there won't be any "empty regions" in the middle of a module.
EDIT: This doesn't cover heap-allocated memory, but that should be something Heap32ListFirst and Heap32ListNext can take care of.
I'm guessing that it's safe to assume that there won't be any "empty regions" in the middle of a module.
EDIT: This doesn't cover heap-allocated memory, but that should be something Heap32ListFirst and Heap32ListNext can take care of.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
