Programming Applications for Microsoft Windows (Microsoft Programming Series)

In this section, we'll bring address spaces, partitions, regions, blocks, and pages all together. The best way to start is by examining a virtual memory map that shows all the regions of address space within a single process. The process happens to be the VMMap sample application presented in Chapter 14. To fully understand the process's address space, we'll begin by discussing the address space as it appears when VMMap is running under Windows 2000 on a 32-bit x86 machine. A sample address space map is shown in Table 13-2. Later I'll discuss the differences between the Windows 2000 and Windows 98 address spaces.

Table 13-2. A sample address space map showing regions under Windows 2000 on a 32-bit x86 machine

The address space map in Table 13-2 shows the various regions in the process's address space. There is one region shown per line, and each line contains six columns.

The first, or leftmost, column shows the region's base address. You'll notice that we start walking the process's address space with the region at address 0x00000000 and end with the last region of usable address space, which begins at address 0x7FFE0000. All regions are contiguous. You'll also notice that almost all the base addresses for non-free regions start on a multiple of 64 KB. This is because of the allocation granularity of address space reservation imposed by the system. A region that does not start on an allocation granularity boundary represents a region that was allocated by operating system code on your process's behalf.

The second column shows the region's type, which is one of the four values—Free, Private, Image, or Mapped—described in the following table.

The way that my VMMap application calculates this column might lead to misleading results. When the region is not free, the VMMap sample application guesses which of the three remaining values applies—there is no function we can call to request this region's exact usage. I calculate this column's value by scanning all of the blocks within the region and taking an educated guess. You should examine my code in Chapter 14 to better understand the way I calculate a column's value.

The third column shows the number of bytes that were reserved for the region. For example, the system mapped the image of User32.DLL at memory address 0x77E20000. When the system reserved address space for this image, it needed to reserve 401,408 bytes. The number in the third column will always be a multiple of the CPU's page size (4096 bytes for an x86).

The fourth column shows the number of blocks within the reserved region. A block is a set of contiguous pages that all have the same protection attributes and that are all backed by the same type of physical storage—I'll talk more about this in the next section of this chapter. For free regions, this value will always be 0 because no storage can be committed within a free region. (Nothing is displayed in the fourth column for a free region.) For the non-free region, this value can be anywhere from 1 to a maximum number of (region size/page size). For example, the region that begins at memory address 0x77E20000 has a region size of 401,408 bytes. Because this process is running on an x86 CPU, for which the page size is 4096 bytes, the maximum number of different committed blocks is 98 (401,408/4096); the map shows that there are 4 blocks in the region.

The fifth column on the line shows the region's protection attributes. The individual letters represent the following: E = execute, R = read, W = write, C = copy-on-write. If the region does not show any of these protection attributes, the region has no access protection. The free regions show no protection attributes because unreserved regions do not have protection attributes associated with them. Neither the guard protection attribute flag nor the no-cache protection attribute flag will ever appear here; these flags have meaning only when associated with physical storage, not reserved address space. Protection attributes are given to a region for the sake of efficiency only and are always overridden by protection attributes assigned to physical storage.

The sixth and last column shows a text description of what's in the region. For free regions, this column will always be blank; for private regions, it will usually be blank because VMMap has no way of knowing why the application reserved this private region of address space. However, VMMap can identify private regions that contain a thread's stack. VMMap can usually detect thread stacks because they will commonly have a block of physical storage within them with the guard protection attribute. However, when a thread's stack is full it will not have a block with the guard protection attribute, and VMMap will be unable to detect it.

For image regions, VMMap displays the full pathname of the file that is mapped into the region. VMMap obtains this information using the ToolHelp functions (mentioned at the end of Chapter 4). In Windows 2000, VMMap can show regions backed by data files by calling the GetMappedFileName function (which does not exist in Windows 98).

Inside the Regions

It is possible to break down the regions even further than shown in Table 13-2. Table13-3 shows the same address space map as Table 13-2, but the blocks contained inside each region are also displayed.

Table 13-3. A sample address space map showing regions and blocks under Windows 2000 on a 32-bitx86 machine

Of course, free regions do not expand at all because they have no committed pages of storage within them. Each block line shows four columns, which I'll explain here.

The first column shows the address of a set of pages all having the same state and protection attributes. For example, a single page (4096 bytes) of memory with read-only protection is committed at address 0x77E20000. At address 0x77E21000, there is a block of 85 pages (348,160 bytes) of committed storage that has execute and read protection. If both of these blocks had the same protection attributes, the two would be combined and would appear as a single 86-page (352,256-byte) entry in the memory map.

The second column shows what type of physical storage is backing the block within the reserved region. One of five possible values can appear in this column: Free, Private, Mapped, Image, or Reserve. A value of Private, Mapped, or Image indicates that the block is backed by physical storage in the paging file, a data file, or a loaded .exe or DLL file, respectively. If the value is Free or Reserve, the block is not backed by any physical storage at all.

For the most part, the same type of physical storage backs all the committed blocks within a single region. However, it is possible for different committed blocks within a single region to be backed by different types of physical storage. For example, a memory-mapped file image will be backed by an .exe or a DLL file. If you were to write to a single page in this region that had PAGE_WRITECOPY or PAGE_EXECUTE_WRITECOPY, the system would make your process a private copy of the page backed by the paging file instead of the file image. This new page would have the same attributes as the original page without the copy-on-write protection attribute.

The third column shows the size of the block. All blocks are contiguous within a region—there will not be any gaps.

The fourth column shows the number of blocks within the reserved region.

The fifth column shows the protection attributes and protection attribute flags of the block. A block's protection attributes override the protection attributes of the region that contains the block. The possible protection attributes are identical to those that can be specified for a region; however, the protection attribute flags PAGE_GUARD, PAGE_NOCACHE, and PAGE_WRITECOMBINE—which are never associated with a region—can be associated with a block.

Address Space Differences for Windows 98

Table 13-4 shows the address space map when the same VMMap program is executed under Windows 98. To conserve space, the range of virtual addresses between 0x80018000 and 0x85620000 is not shown.

Table 13-4. A sample address space map showing blocks within regions under Windows 98

The biggest difference between the two address space maps is the lack of information offered under Windows 98. For example, each region and block will reflect whether the area of address space is Free, Reserve, or Private. You will never see the words Mapped or Image because Windows 98 does not offer the additional information indicating whether the physical storage backing the region is a memory-mapped file or is contained in an .exe or a DLL's file image.

You'll notice that most of the region sizes are exact multiples of the allocation granularity (64 KB). If the sizes of the blocks contained within a region do not add up to a multiple of the allocation granularity, there is frequently a block of reserved address space at the end of the region. This block is whatever size is needed to bring the region to an allocation granularity boundary (64 KB). For example, the region starting at address 0x00530000 consists of 2 blocks: a 4-KB committed block of storage and a reserved block that occupies a 60-KB range of memory addresses.

Finally, the protection flags never reflect execute or copy-on-write access because Windows 98 does not support these flags. The three protection attribute flags—PAGE_NOCACHE, PAGE_WRITECOMBINE, and PAGE_GUARD— are also not supported. Because the PAGE_GUARD flag is not supported, VMMap uses a more complicated technique to determine whether a region of address space is reserved for a thread's stack.

You will notice that, unlike Windows 2000, in Windows 98 the region of address space between 0x80000000 and 0xBFFFFFFF can be examined. This is the partition that contains the address space shared by all 32-bit applications. As you can see, the four system DLLs are loaded into this region of address space and are therefore available to all processes.