when watching memory map page in olly debug (very fine thing)

[attachment=22617:mm.jpg]

some things are clear for example loaded dlls and its sections (those blocks that are described as Image), (one thing unclear why here are loaded .realoc data as it seem not needed in memory, i dont know) - but the other ones are unclear , i mean those described as Map and Priv - does maybe someone know what it is, what it could be, why it is needed - i would wery like to get know whats that

also yet one intriguing question - i see there .data sections for each modules but data is only static and non zero initialized data ,I wonder where in such blocks lays mallocked data or zero initialized static data.. Is there some way to get know where each module mallocked (or static zero initialized data) lays here?

Uninitialized data has been put in BSS (Base Storage Segment) for some hundred years of computer technology.

malloced data is taken from a block that gets requested from the OS. sbrk() and brk() are the ones.

I guess .reloc could probably be reclaimed - I don't think an image (exe/dll) will be moved again after it's loaded. Though I've never seen a process reclaim .reloc pages for other purposes yet.

As far as I can tell from the picture, "Map" stands for memory-mapped-file. Memory mapped files are an operating system feature that let you map a file or a portion of a file directly to memory - reads and writes to the memory will impact the file without having to fread/fwrite/etc.

All of the other stuff (marked as "Priv") are anything the process has allocated dynamically. These could be heaps, stacks, JITted code (if you see any pages outside of the image regions that are marked as execute, it's JITted or injected code), or whatever else the program was written to allocate. It depends on the program (which language, runtime library, manual memory management, etc it uses).

The BSS pages in your picture are expanded in the middle of the image pages by the loader. They are fixed in that position because the executable was built to expect them at that location.

The pages marked as "RW Guard" are guard pages used to detect stack overflows by triggering a special exception if they are accessed.

I guess .reloc could probably be reclaimed - I don't think an image (exe/dll) will be moved again after it's loaded. Though I've never seen a process reclaim .reloc pages for other purposes yet.

As far as I can tell from the picture, "Map" stands for memory-mapped-file. Memory mapped files are an operating system feature that let you map a file or a portion of a file directly to memory - reads and writes to the memory will impact the file without having to fread/fwrite/etc.

All of the other stuff (marked as "Priv") are anything the process has allocated dynamically. These could be heaps, stacks, JITted code (if you see any pages outside of the image regions that are marked as execute, it's JITted or injected code), or whatever else the program was written to allocate. It depends on the program (which language, runtime library, manual memory management, etc it uses).

The BSS pages in your picture are expanded in the middle of the image pages by the loader. They are fixed in that position because the executable was built to expect them at that location.

The pages marked as "RW Guard" are guard pages used to detect stack overflows by triggering a special exception if they are accessed.

alright, tnx

i overlooked this 70 MB .bss sections (it seemed that it not showed previously but probably i was blind) - seem to be a bit large, it seemed to me that i got more like 20 MB static arrays here but again probably im blind in counting (this app is my pure c + winapi rasterizer small 300 kb exe with no redistribuables)

system dlls seem to not have .bss sections (it seemed strange for me but maybe they are written such way - mallocs instead bss)

stack seem to have 16 kb only but there is adress space for potential 2 MB

1. those "Map" blocks still confuse me, there ara about 20 of them mostly small, most seem to be data (some read some radwrite) but some are executable (and mysterious - not described)

do such memory mapped meand more like real disk file that is mapped or this is more like shared physical ram blocks ? are those really disk files? this is confucing - maybe someone is able to clear it a bit

2. thise privs also confuse me yet - i wonder if those are just mallocked buffers - sad there is no description (if so) which module mallocked them

(i mean if loaded dll's if some loader external to those dlls (like stack was probably allocked by some loader or what) or my prog

I could probably make same experiment by logging my mallocks adresses and comparing them to such blocks.

maybe those privs together make juz a mallocked heap? if someone could add something to this picture it would be fine

ps. some privs here are marked executable but as this is moderately simple winapi app there should be no jitted or injected code.. so i dont know how to explain this

system dlls seem to not have .bss sections (it seemed strange for me but maybe they are written such way - mallocs instead bss)

If the uninitialized data is small, the compiler might decide to include it in the initialized data section instead.

stack seem to have 16 kb only but there is adress space for potential 2 MB

The stack overflow handling behavior can expand the stack on the fly (if it's set up to do so) and resume execution gracefully if the stack was expanded safely.

1. those "Map" blocks still confuse me, there ara about 20 of them mostly small, most seem to be data (some read some radwrite) but some are executable (and mysterious - not described)

do such memory mapped meand more like real disk file that is mapped or this is more like shared physical ram blocks ? are those really disk files? this is confucing - maybe someone is able to clear it a bit

I haven't personally used memory mapped files more than once. I believe you can use them to share data between two processes with or without "real" disk files, but I've never actually tried that.

2. thise privs also confuse me yet - i wonder if those are just mallocked buffers - sad there is no description (if so) which module mallocked them
(i mean if loaded dll's if some loader external to those dlls (like stack was probably allocked by some loader or what) or my prog

I could probably make same experiment by logging my mallocks adresses and comparing them to such blocks.

maybe those privs together make juz a mallocked heap? if someone could add something to this picture it would be fine

ps. some privs here are marked executable but as this is moderately simple winapi app there should be no jitted or injected code.. so i dont know how to explain this

"Priv" probably stands for "Private bytes" (which is what a few process memory reporting tools on Windows call a process' memory usage).

As far as I know, here's how it works:

- VirtualAlloc is what allocates the pages you see in your screenshot, and VirtualProtect sets their flags. However, a heap implementation is free to make as many different page allocations as it wants to, even if they are not all in one block of contiguous address space. Since page sizes are a fixed size (usually 4096 bytes for a typical 32-bit Windows process), there may be some unused space in them that the runtime library's memory manager hasn't specifically made part of its heap yet.

The different DLLs in your process are free to share a heap, or use multiple separate heaps as well. They avoid overlapping with each other because VirtualAlloc won't let you allocate pages which are already allocated.

As far as your unknown Priv+execute pages go, any third-party applications on your computer may install system hooks which cause DLLs to be loaded into your processes even if they aren't normally part of your program. Mice and keyboard vendors, for example, may with software that will load various DLLs into (nearly) every process in order to handle special shortcut keys or gestures. It might also be something Olly is doing (I haven't used Olly - I have my own tool to show the same kinds of information, except I know for certain that it does not inject anything).

system dlls seem to not have .bss sections (it seemed strange for me but maybe they are written such way - mallocs instead bss)

If the uninitialized data is small, the compiler might decide to include it in the initialized data section instead.

stack seem to have 16 kb only but there is adress space for potential 2 MB

The stack overflow handling behavior can expand the stack on the fly (if it's set up to do so) and resume execution gracefully if the stack was expanded safely.

1. those "Map" blocks still confuse me, there ara about 20 of them mostly small, most seem to be data (some read some radwrite) but some are executable (and mysterious - not described)

do such memory mapped meand more like real disk file that is mapped or this is more like shared physical ram blocks ? are those really disk files? this is confucing - maybe someone is able to clear it a bit

I haven't personally used memory mapped files more than once. I believe you can use them to share data between two processes with or without "real" disk files, but I've never actually tried that.

2. thise privs also confuse me yet - i wonder if those are just mallocked buffers - sad there is no description (if so) which module mallocked them
(i mean if loaded dll's if some loader external to those dlls (like stack was probably allocked by some loader or what) or my prog

I could probably make same experiment by logging my mallocks adresses and comparing them to such blocks.

maybe those privs together make juz a mallocked heap? if someone could add something to this picture it would be fine

ps. some privs here are marked executable but as this is moderately simple winapi app there should be no jitted or injected code.. so i dont know how to explain this

"Priv" probably stands for "Private bytes" (which is what a few process memory reporting tools on Windows call a process' memory usage).

As far as I know, here's how it works:

- VirtualAlloc is what allocates the pages you see in your screenshot, and VirtualProtect sets their flags. However, a heap implementation is free to make as many different page allocations as it wants to, even if they are not all in one block of contiguous address space. Since page sizes are a fixed size (usually 4096 bytes for a typical 32-bit Windows process), there may be some unused space in them that the runtime library's memory manager hasn't specifically made part of its heap yet.

The different DLLs in your process are free to share a heap, or use multiple separate heaps as well. They avoid overlapping with each other because VirtualAlloc won't let you allocate pages which are already allocated.

As far as your unknown Priv+execute pages go, any third-party applications on your computer may install system hooks which cause DLLs to be loaded into your processes even if they aren't normally part of your program. Mice and keyboard vendors, for example, may with software that will load various DLLs into (nearly) every process in order to handle special shortcut keys or gestures. It might also be something Olly is doing (I haven't used Olly - I have my own tool to show the same kinds of information, except I know for certain that it does not inject anything).

Here, this is not me that uses this memory map, but the system - if priv are private for this wirtual space maybe map means blocks shared for all or many wirtual spaces (?)

As to private, i made some experiment I was writing before and printed the adresses of two mallocked buffers I was using in my map and those appeared as a Priv RW here; Wonder if all privs here are just some mallocks 1-1

Yet one thing im not using many mallocks in my program (im using almost exclusively only ststic arrays) Im quite sure that in this program Im using only two reallocks yet thios screenshot is taken at program startup so they was not yet fires so all those privs are probably called by

1) some loader 2) some loaded dll's startups (if those are able to fire such startup thing )

- wonder if there should be an option to do not those static like but manual and deferred loading of those dll-s so i could wath it at runtime and see as more chunks appear... (Im interested in such kind of tings but msdn is usually to much confusing yet for me)

(- as to injections i got avast antivir installed he really injects something even if disabled, once he was killing my app that was hackishly stripped for size as he found it as malware)

Yet i wonder if is dll is mallocking data does such dll hold it out of my wirtual process space or it is in it? such dll data is probably not needed to be seen by my process (at least in 99% of cases) but those picture seem to suggest that it is loaded in the same wirtual space - not sure

Can you say yet what you mean by many heaps? each such heap is in different wirtual space or those heaps lays in one wirtual space but are defined over some distinct blocks, or what? tnx for info, if i find some more info i cand extend this picture yet in some details, very interesting things, much usefull for some kind of things (like taking care whats going on)

Wonder if all privs here are just some mallocks 1-1

They're not 1-to-1, otherwise you'd have very inefficient use of RAM. For example if you allocated two blocks of 16 bytes apiece, they will probably go in the same Priv page. You wouldn't want to have a separate 4K priv page for each one.

Can you say yet what you mean by many heaps? each such heap is in different wirtual space or those heaps lays in one wirtual space but are defined over some distinct blocks, or what? tnx for info, if i find some more info i cand extend this picture yet in some details, very interesting things, much usefull for some kind of things (like taking care whats going on)

It's implementation dependent (it's up to the memory manager). For example, the .Net Large Object Heap probably puts its pages in a different area than the generational heap(s) to avoid fragmentation on the LOH from impacting the generational heap. The MSVCRT heap can also do the same kind of thing. You'll likely see completely different memory management schemes between different vendors.

Olly debug builds a virtual memory space so the program being debugged can be viewed. Every program whether normal,dll, or text will be broken down into a perceived memory space in Olly. As far as Private goes... It's privileaged memory space and Windows defines it based on it's system memory map. With this space you must be careful! This changes on everyone's elses system based on their overall system memory(physically-installed into their system). Olly is just displaying the code for you regardless. (Nypyren and other's are rite I'm just padding here to help with your understanding of what's going on). Your memory can also be displayed into 1-byte, 2-byte(word), 4-byte(longword-old motorola 68k wording), etc,etc. Again, just for reference purposes. For example, load a picture file into olly and watch what happens. Or, a sound file. That's the great thing about olly debug; It'll let you debug anything!

Essentially, It's all for reference for debugging code. There is no physical memory addressing going on with olly. In fact, only windows assigns(and reallocates) and it IS different each time because of competing memory space.

And in closing, the 'heap' is sometimes called STACK memory. And olly does monitor stack calls very good. Be careful not to confuse your program's stack calls with Win32(System) calls. Especially, late night debugging sessions . You might go into a rabbit hole and not get back out!