|Home » Gallery
How Virtual Memory Works
Memview maps virtual memory for a given process. It can be used on its own but is meant to be used together with X-tool. If you run it independently of X-tool you have to input process numbers in hex yourself.
All Win32/64 memory is virtual, i.e. it exists on disk and is only read into RAM when needed. This is the basis of XP's memory protection scheme, one of the reasons a stand-alone 3.51 workstation can get the coveted Orange Book C2 classification.
These segments of memory have to be swappable, and a reasonable swapping unit has to be used. This unit, called a page, is currently 4KB on Intel platforms and 8KB on Alpha platforms (on MIPS it is theoretically variable but MIPS is no longer supported). A page in RAM is called a page frame.
The rules of memory management don't stop there. Inasmuch as actual RAM is managed by the operating system (XP's virtual memory manager or VMM) in Kernel Mode, only User Mode addresses have any actual bearing on the logic of a program. Where the VMM places code and data is totally immaterial, but the application itself must believe its memory is real.
Every Win32/64 process believes:
- It is alone in the computer.
- It has exclusive access to the computer's resources.
- It has 4GB of memory to access.
The operating system and device drivers are mapped universally into the address space of each running process and always have the same virtual addresses; and at least on XP all 'dependencies', i.e. DLLs, are mapped individually as well. Almost all applications run under Win32/64 have the same starting address: 00400000h or 4MB.
Thus the virtual and not the real addresses become important to the program: if an application counts on having linear access to a database register encompassing a gigabyte or more, then the addresses mapped in virtual memory for this register must necessarily be contiguous. One distinguishes between reserving memory (i.e. getting the necessary virtual address space) and committing memory (i.e. getting physical backup).
And while the allocation granularity for Win32/64 is equal to the size of the swappable page and can vary from platform to platform, the granularity of reserved memory is always the same: 64KB.
Following are Memview's column headers.
- Base. This is the base of the allocation itself. This will be on a page boundary.
- Region. The address of the reserved memory region the allocation belongs to. This will always be on a 64KB boundary.
- Access Request. The initial protection attributes of the allocation. These attributes are quite sophisticated on XP, less than paraplegic on 9x - 9x has no memory protection scheme whatsoever. The following can apply on XP or later:
- PAGE_READONLY, PAGE_READWRITE. Fairly self-explanatory.
- PAGE_WRITECOPY. A cutie. Means that when any attempt is made to write to the page, a copy will be made and the write will take place on the copy instead. It is the implementation of this attribute which makes Win32/64's incredible memory management scheme possible. Applications are not 'loaded' into memory - their disk images are merely marked as being their own virtual memory backup. Applications can thus load almost instantaneously, and only when pages are actually needed in memory are they read in - and then by the VMM in Kernel Mode. Because global data in an application can be expected to change during the life of a program the corresponding pages on disk may not be altered - we're talking about the actual image file here - and thus part of the application starts to live in the neutral territory of the system swap files - the data sections in question are marked as PAGE_WRITECOPY.
- PAGE_EXECUTE. The page can be executed (you can't just jump to any old address in XP).
- PAGE_EXECUTE_READ. The page can be executed and read (but not written).
- PAGE_EXECUTE_READWRITE. The page can be both executed, read, and written.
- PAGE_EXECUTE_WRITECOPY. As PAGE_EXECUTE_READWRITE, but an attempt to alter the page will cause it to be copied to neutral territory first.
- PAGE_GUARD. Used with any attribute except PAGE_NOACCESS, will notify the process that the underlying region has been entered. XP uses two PAGE_GUARD regions around User Mode memory to protect the operating system.
- PAGE_NOCACHE. A modifier, must be used with any attribute except PAGE_NOACCESS: no caching of the committed regions of pages allowed. Used by device drivers.
- Size. The size of the allocation, expressed in hex.
- Status. Must be one and only one of the following:
- MEM_FREE. The memory is neither reserved nor committed.
- MEM_RESERVE. The memory is reserved. This range of addresses may not be used by any other memory allocation call.
- MEM_COMMIT. The memory has physical backup, and is in use.
- Current Access. Memory attributes can be changed at any time. These are the attributes at the time the snapshot was taken.
- Type. The type of pages in the region:
- MEM_IMAGE. The pages are mapped into the view of an image section.
- MEM_MAPPED. The pages are mapped into the view of a section.
- MEM_PRIVATE. The pages are not shared with other processes.
You can get a dump of any MEM_COMMIT allocation not marked with either the PAGE_GUARD or PAGE_NOACCESS modifiers by double clicking on it.
Walking Through Process Memory
It is quite easy - once you're used to it - to see exactly what's going on in an application with Memview.
- Look for the application image itself at 00400000. You should find five sections (allocations) or so all sharing the same region. (If you're not sure where the application loads and you're running XP, check with X-perf first.) The last allocation in the region for Win32/64 GUI executables should be the resource section, and if the application contains version info you should see it here.
- The ISV dependencies are normally mapped immediately above the application itself starting at 01000000, but this can vary.
- Operating system modules are mapped successively down from the upper limit of the User Mode address space. (Again, if you are running XP, check with X-perf for the exact identity and address mapping of each module.) Operating system components are meticulously rebased from this boundary (normally 80000000 or 2GB) on down so as to use up every available virtual page and to not overlap. (On XP, look for the clever ntdll.dll at 77f60000).
- Find the process environment block at 00010000.
What's in a Number
The System process ID seems inviolable at 2. Just enter it into Memview's Open dialog and click OK.
Memview & X-tool
Memview is meant to be used with X-tool. Double click on a process in X-tool to fire it up.
File size: 7.5KB.