Graphical memory layout for notepad process

I've seen several sites on the internet, which describes how the virtual memory layout looks like for a Win32 application. But these sites seldom shows a virtual memory layout with real addresses, they tend to show only conceptual views. So I made a graphical layout of my own, based on real virtual addresses.

Before proceeding, just a short recap about virtual addresses. For a 32 bit application, each process got its own private memory space, which goes from 0 to 2³²−1 (DEC: 4294967295, HEX: FFFFFFFF), where each position occupy a single byte. We normally say that a process has about 4 GB of memory. However, only the first 2 GB is dedicated as user-mode memory. The remaining 2 GB is occupied by the kernel-mode memory. (It is possible to extend the user-mode memory from 2 GB to 3 GB, but that is not considered in this post)

I'm using Process Explorer from Sysinternals, to find out the load addresses and image sizes. I'm using Windows Vista 32 bit as platform. Windows Vista can take advantage of the Address Space Layout Randomization (ASLR) feature. ASLR, among other things, will randomly choose a load address for the EXE and DLLs. I may have a specific post about ASLR in the future. However, in my case, the ASLR is in action, which can be verified from the screenshot below.



Screenshot of Process Explorer, showing some of the loaded images

Note that notepad.exe is mapped to the address 0xCF0000 and occupy 0x28000 bytes. Since ASLR is in action, the load address will probably differ in another boot session. Yes, that's right. A new load address will be given to notepad.exe each time you reboot your computer. But the load address remains if you only restart notepad during the same boot session.

Since the load address and the size of the image is known, I simply enter this information to Excel and plot a diagram. The diagram below is made from another boot session.

I've colored the upper 2 GB (kernel-mode memory) black. Process Explorer does not really tell us what's going on there. As you can see, the images does not occupy that much space. There is a lot of space for the heap, stacks and so on.

Unfortunately I was not able to use hex numbers on the Y-axis. But 2 147 483 648 is equal to 0x80000000, which is half of the 32 bit address space.