Sign in to follow this  

Process memory

This topic is 3740 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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().

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

This topic is 3740 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this