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).