Windows® Internals, Sixth Edition, Part 2

A control area in turn points to subsection structures that describe the mapping information for each section of the file (read-only, read/write, copy-on-write, and so on). The control area also points to a segment structure allocated in paged pool, which in turn points to the prototype PTEs used to map to the actual pages mapped by the section object. As described earlier in the chapter, process page tables point to these prototype PTEs, which in turn map the pages being referenced.

Figure 10-35. Internal section structures

Although Windows ensures that any process that accesses (reads or writes) a file will always see the same, consistent data, there is one case in which two copies of pages of a file can reside in physical memory (but even in this case, all accessors get the latest copy and data consistency is maintained). This duplication can happen when an image file has been accessed as a data file (having been read or written) and then run as an executable image (for example, when an image is linked and then run—the linker had the file open for data access, and then when the image was run, the image loader mapped it as an executable). Internally, the following actions occur:

If the executable file was created using the file mapping APIs (or the cache manager), a data control area is created to represent the data pages in the image file being read or written.

When the image is run and the section object is created to map the image as an executable, the memory manager finds that the section object pointers for the image file point to a data control area and flushes the section. This step is necessary to ensure that any modified pages have been written to disk before accessing the image through the image control area.

The memory manager then creates a control area for the image file.

As the image begins execution, its (read-only) pages are faulted in from the image file (or copied directly over from the data file if the corresponding data page is resident).

Because the pages mapped by the data control area might still be resident (on the standby list), this is the one case in which two copies of the same data are in two different pages in memory. However, this duplication doesn’t result in a data consistency issue because, as mentioned, the data control area has already been flushed to disk, so the pages read from the image are up to date (and these pages are never written back to disk).

EXPERIMENT: Viewing Control Areas

To find the address of the control area structures for a file, you must first get the address of the file object in question. You can obtain this address through the kernel debugger by dumping the process handle table with the !handle command and noting the object address of a file object. Although the kernel debugger !file command displays the basic information in a file object, it doesn’t display the pointer to the section object pointers structure. Then, using the dt command, format the file object to get the address of the section object pointers structure. This structure consists of three pointers: a pointer to the data control area, a pointer to the shared cache map (explained in Chapter 11), and a pointer to the image control area. From the section object pointers structure, you can obtain the address of a control area for the file (if one exists) and feed that address into the !ca command.

For example, if you open a PowerPoint file and display the handle table for that process using !handle, you will find an open handle to the PowerPoint file as shown here. (For information on using !handle, see the “Object Manager” section in Chapter 3 in Part 1.)lkd> !handle 1 f 86f57d90 File . . 0324: Object: 865d2768 GrantedAccess: 00120089 Entry: c848e648 Object: 865d2768 Type: (8475a2c0) File ObjectHeader: 865d2750 (old version) HandleCount: 1 PointerCount: 1 Directory Object: 00000000 Name: \Users\Administrator\Documents\Downloads\ SVR-T331_WH07 (1).pptx {HarddiskVolume3}

Taking the file object address (865d2768 ) and formatting it with dt results in this:lkd> dt nt!_FILE_OBJECT 865d2768 +0x000 Type : 5 +0x002 Size : 128 +0x004 DeviceObject : 0x84a62320 _DEVICE_OBJECT +0x008 Vpb : 0x84a60590 _VPB +0x00c FsContext : 0x8cee4390 +0x010 FsContext2 : 0xbf910c80 +0x014 SectionObjectPointer : 0x86c45584 _SECTION_OBJECT_POINTERS

Then taking the address of the section object pointers structure (0x86c45584) and formatting it with dt results in this:lkd> dt 0x86c45584 nt!_SECTION_OBJECT_POINTERS +0x000 DataSectionObject : 0x863d3b00 +0x004 SharedCacheMap : 0x86f10ec0 +0x008 ImageSectionObject : (null)