Knowing process' memory range

[devouredelysium]

Hello.

Anyone knows if it is possible to get the memory range of an arbitrary process? This is, I know we can search from 0x400000 to 0x7FFF0000 by brute force, but many of this space will return bad results from ReadProcessMemory, so I'd like to know if it's possible to programatically get the defined range, so I can use it. I've been trying to use the ProcessModuleCollection collection off the Process class (in .net) but it does not seem to cover the whole range of memory of the programs. Any help?

[Nesox]

Entry of the first module - End of last module

[Bobbysing]

You'd rather want to use VirtualQueryEx as it also tells you about pages outside of the modules.

[Cypher]

Call GetSystemInfo to get the minimum and maximum addresses, along with the page size. Then call VirtualQuery(Ex) beginning at the minimum and up to the maximum, adding region size at each loop iteration.

[devouredelysium]

Hello. Thanks for the answers. From what I see, GetSystemInfo will get me the minimum and maximum addresses. Now what I do not understand is what VirtualQueryEx will do here.

a) Is it correct to assume that all the memory from the minimum to the maximum addresses returned by GetSystemInfo will be used by the process?
b) If yes, then why would I use VirtualQueryEx?

What do you mean by adding region size at each loop iteration?

Thanks

[amadmonk]

Hello. Thanks for the answers. From what I see, GetSystemInfo will get me the minimum and maximum addresses. Now what I do not understand is what VirtualQueryEx will do here.

a) Is it correct to assume that all the memory from the minimum to the maximum addresses returned by GetSystemInfo will be used by the process?

Most emphatically, no.

b) If yes, then why would I use VirtualQueryEx?

What do you mean by adding region size at each loop iteration?

Thanks

VirtualQueryEx needs to be "walked upwards" through memory to give a complete block accounting of allocated memory. You'll have to read the MSDN docs for the API to understand it. Experiment a bit on your own process, and you'll see all kinds of little blocks allocated for various PE sections, heap, and so on.

The only guaranteed-to-be-allocated contiguous block of memory in a process is a block returned by VQE. Processes do not have solid walls of memory; they have numerous little chunks of address space stitched together by the virtual memory manager. Cypher's method of determining valid memory is the only correct one. Actually you can skip the call to GetSystemInfo if you're lazy, since VQE will show you what's valid and what's not (but you may end up querying more than you need to, if you do).

[devouredelysium]

Ah. Thanks, that what I needed to know. I'll now try to work out the code.

edit: Well, aren't the pages VirtualQueryEx returns the same as the ProcessModule object that the Process class returns?
edit2: Well, now that I've searched it on MSDN, http://msdn.microsoft.com/en-us/libr...s.modules.aspx , they seem to be clearly different things.

[amadmonk]

They are related, but not the same.

Loaded modules use memory blocks allocated by the virtual memory system (which VQE will show), but there are other blocks (notably heap, but there are others) that are not part of modules at all.

[Cypher]

Most emphatically, no.



VirtualQueryEx needs to be "walked upwards" through memory to give a complete block accounting of allocated memory. You'll have to read the MSDN docs for the API to understand it. Experiment a bit on your own process, and you'll see all kinds of little blocks allocated for various PE sections, heap, and so on.

The only guaranteed-to-be-allocated contiguous block of memory in a process is a block returned by VQE. Processes do not have solid walls of memory; they have numerous little chunks of address space stitched together by the virtual memory manager. Cypher's method of determining valid memory is the only correct one. Actually you can skip the call to GetSystemInfo if you're lazy, since VQE will show you what's valid and what's not (but you may end up querying more than you need to, if you do).

Afaik you still need GetSystemInformation if you want to get the correct page size for the machine. (I'm a portability nazi when it comes to Windows programming :P)

[devouredelysium]

Thanks all, did the library in c# and to my surprise it does not look slower than MHS.

[amadmonk]

Afaik you still need GetSystemInformation if you want to get the correct page size for the machine. (I'm a portability nazi when it comes to Windows programming :P)

Bah. Pages will always be 4k in my book.

Are we using larger pages anywhere for reals now?

(Edit: oh, I forgot about the large pages in the kernel. But still... that's the kernel...)

[amadmonk]

Thanks all, did the library in c# and to my surprise it does not look slower than MHS.

I don't know where everyone got this built-in belief that C# is always slow. Sometimes it is (especially in situations where the GC is super-active), but usually it's comparable to C/C++ speeds (the JIT'ter/NGEN really does work, honest).

In fact, IIRC, IronPython (the .Net-bound Python flavor) actually outperforms CPython (the native C Python flavor) on a number of benchmarks. I think that the garbage collection sometimes frees cycles during execution (allows for "lazy" cleanups rather than being "correct" in C/C++ with free/delete). Resource cleanup can be expensive, so this means that your slowdowns happen after all the excitement is over, not during the action -- which can, in some circumstances, dramatically speed up execution times.

Of course, you could write C++/asm/whatever to do this too, but the point is: don't just assume something will be slow (or fast). Try it, benchmark it, and then see if it's fast enough for your purposes.

[devouredelysium]

Well I have experience in a lot of cases where i have similar c++/c# codes and c++ is way faster than c#, just that.

[amadmonk]

Yes, there are definitely cases where C++ outperforms C#. In fact, given all else equal, and given tests that don't emphasize the benefits of garbage collection, C++ should usually outperform C#. But not usually by much (it depends), and not always. Plus the ease-of-development/prototyping in C# (for me) far outweighs the gain of a few milliseconds that I'll never see because it's eaten up in an input processing loop somewhere.

But, to each his own. I know that to C++ purists like Cypher, even mentioning scripting/VM languages is nearly heresy...

[Cypher]

Bah. Pages will always be 4k in my book.

Are we using larger pages anywhere for reals now?

(Edit: oh, I forgot about the large pages in the kernel. But still... that's the kernel...)

AMD64? Itanium? I like to write architecture portable code if at all possible. It's certainly saved me a SHITTON of work recently now that I've been doing lots of native AMD64 programming.

It's also great to do because you learn what to avoid, the correct way to do things, etc. and shield yourself from other potential problems.

Plus, I can annoy people by pointing out hundreds of potential portability problems in their code bases.