Section Objects

As you'll remember from the section on shared memory earlier in the chapter, the section object, which the Windows subsystem calls a file mapping object, represents a block of memory that two or more processes can share. A section object can be mapped to the paging file or to another file on disk.

The executive uses sections to load executable images into memory, and the cache manager uses them to access data in a cached file. (See Chapter 11 for more information on how the cache manager uses section objects.) You can also use section objects to map a file into a process address space. The file can then be accessed as a large array by mapping different views of the section object and reading or writing to memory rather than to the file (an activity called mapped file I/O). When the program accesses an invalid page (one not in physical memory), a page fault occurs and the memory manager automatically brings the page into memory from the mapped file. If the application modifies the page, the memory manager writes the changes back to the file during its normal paging operations (or the application can flush a view by using the Windows FlushViewOfFile function).

Section objects, like other objects, are allocated and deallocated by the object manager. The object manager creates and initializes an object header, which it uses to manage the objects; the memory manager defines the body of the section object. The memory manager also implements services that user-mode threads can call to retrieve and change the attributes stored in the body of section objects. The structure of a section object is shown in Figure 7-29.

Figure 7-29. A section object

Table 7-16 summarizes the unique attributes stored in section objects.

Table 7-16. Section Object Body Attributes

Attribute	Purpose
Maximum size	The largest size to which the section can grow in bytes; if mapping a file, the maximum size is the size of the file.
Page protection	Page-based memory protection assigned to all pages in the section when it is created.
Paging file/Mapped file	Indicates whether the section is created empty (backed by the paging file as explained earlier, page file backed sections use page-file resources only when the pages need to be written out to disk) or loaded with a file (backed by the mapped file).
Based/Not based	Indicates whether a section is a based section, which must appear at the same virtual address for all processes sharing it, or a nonbased section, which can appear at different virtual addresses for different processes.

EXPERIMENT: Viewing Section Objects

With the Object Viewer (Winobj.exe from http://www.sysinternals.com from the book's companion CD or Winobj.exe in the Platform SDK), you can see the list of sections that have global names. You can list the open handles to section objects with any of the tools described in the Object Manager section in Chapter 3 that list the open handle table. (As explained in Chapter 3, these names are stored in the object manager directory \Base-NamedObjects.)

Using Process Explorer or Handles.exe (both from http://www.sysinternals.com) or the Windows resource kit Oh.exe (Open Handles) tool, you can list the open handles to section objects. For example, the following command displays all open handles to objects of type section, whether or not they have names. (A section must have a name only if other processes need to open it by name.)

c:\> oh -t section -a 00000008 System            Section  0070 0000008C smss.exe          Section  0004 000000A4 csrss.exe         Section  0004 000000A4 csrss.exe         Section  0024 000000A4 csrss.exe         Section  0038 000000A4 csrss.exe         Section  0040 \NLS\NlsSectionUnicode 000000A4 csrss.exe         Section  0044 \NLS\NlsSectionLocale 000000A4 csrss.exe         Section  0048 \NLS\NlsSectionCType 000000A4 csrss.exe         Section  004c \NLS\NlsSectionSortkey 000000A4 csrss.exe         Section  0050 \NLS\NlsSectionSortTbls 000000A0 winlogon.exe      Section  0004 000000A0 winlogon.exe      Section  0034 000000A0 winlogon.exe      Section  0168 \BaseNamedObjects \mmGlobalPnpInfo §

You can also use Process Explorer from http://www.sysinternals.com to view mapped files. Select DLLs from the Lower Pane View entry of the View menu. Files marked with an asterisk in the MM column are mapped files (rather than DLLs and other files the image loader loads as modules). Here's an example:

The data structures maintained by the memory manager that describe mapped sections are shown in Figure 7-30. These structures ensure that data read from mapped files is consistent, regardless of the type of access (open file, mapped file, and so on).

Figure 7-30. Internal section structures

For each open file (represented by a file object), there is a single section object pointers structure. This structure is the key to maintaining data consistency for all types of file access as well as to providing caching for files. The section object pointers structure points to one or two control areas. One control area is used to map the file when it is accessed as a data file, and one is used to map the file when it is run as an executable image.

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.

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:

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

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

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

4. As the image begins execution, its (read-only) pages are faulted in from the image file.

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 below. (For information on using !handle, see the "Object Manager" section in Chapter 3.)

lkd> !handle 1 f 5c4 file . . 0284: Object: 8645c038 GrantedAccess: 00120089 Object: 8645c038 Type: (867ddca0) File     ObjectHeader: 8645c020         HandleCount: 1 PointerCount: 1         Directory Object: 00000000 Name: \slides\ntint\new\ 3-systemarchitecture.ppt {HarddiskVolume1}

Taking the file object address (8645c038) and formatting it with dt results in this:

lkd> dt nt!_file_object 8645c038 nt!_FILE_OBJECT    +0x000 Type               : 5    +0x002 Size               : 112    +0x004 DeviceObject       : 0x86742e30    +0x008 Vpb                : 0x867a3090    +0x00c FsContext          : 0xe2786530    +0x010 FsContext2         : 0xe309a378    +0x014 SectionObjectPointer : 0x85512fec

Then taking the address of the section object pointers structure (0x85512fec) and formatting it with dt results in this:

lkd> dt nt!_section_object_pointers 0x85512fec nt!_SECTION_OBJECT_POINTERS    +0x000 DataSectionObject : 0x8564f8a0    +0x004 SharedCacheMap   : (null)    +0x008 ImageSectionObject : (null)

Finally, use !ca to display the control area using the address:

lkd> !ca 0x8564f8a0 ControlArea @8564f8a0   Segment:    e3817528    Flink           0    Blink         0   Section Ref        1    Pfn Ref       25c    Mapped Views  1   User Ref           2    WaitForDel      0    Flush Count   0   File Object 85774580    ModWriteCount   0    System Views  0   Flags (9008080) File WasPurged HadUserReference Accessed   File: \slides\ntint\new\3-systemarchitecture.ppt

Another technique is to display the list of all control areas with the !memusage command. The following excerpt is from the output of this command:

kd> !memusage  loading PFN database loading  (99% complete)               Zeroed:         9 (       36 kb)                 Free:         0 (        0 kb)              Standby:      2103 (     8412 kb)             Modified:       300 (     1200 kb)      ModifiedNoWrite:         1 (        4 kb)         Active/Valid:     30318 (   121272 kb)           Transition:         3 (       12 kb)              Unknown:         0 (        0 kb)                TOTAL:     32734 (   130936 kb)     Building kernel map     Finished building kernel map     Usage  Summary(inKb): Control   Valid    Standby  Dirty  Shared  Locked PageTables   name 8119b608    3000     528      0      0      0     0   mapped_file ( WINWORD.EXE ) 849e7c68      96       0      0      0      0     0     No  NameforFile 8109c388      24       0      0      0      0     0   mapped_file ( DEVDTG.PKG ) 81402488     236       0      0      0      0     0     No  NameforFile 80fba0a8     268       0      0      0      0     0   mapped_file ( kernel32.pdb ) 810ab168    1504     380      0      0      0     0   mapped_file ( OUTLLIB.DLL ) 81126a08       0     276      0      0      0     0   mapped_file ( H ) 81112d28     656       0      0      0      0     0     No  Namefor File

The Control column points to the control area structure that describes the mapped file. You can display control areas, segments, and subsections with the kernel debugger !ca command. For example, to dump the control area for the mapped file Winword.exe in this example, type the !ca command followed by the Control number, as shown here:

kd> !ca 8119b608 ControlArea  @8119b608   Segment:     e2c28000  Flink             0  Blink:            0   SectionRef          1  Pfn Ref         372  MappedViews:      1   User  Ref           2  Subsections       6  Flush  Count:     0   File  Object 8213fb98  ModWriteCount     0  SystemViews:      0   WaitForDel          0  PagedUsage     3000  NonPaged Usage  100   Flags (90000a0) ImageFile HadUserReference Accessed    File:\Program Files\MicrosoftOffice\Office\WINWORD.EXE Segment  @ e2c28000:    Base address        0  Total  Ptes       86a  NonExtendPtes:       86a     Image commit      d7  ControlArea  8119b608  SizeOfSegment:  86a000     Image Base         0  Committed           0  PTETemplate:    919b6c38     Based Addr  30000000  ProtoPtes    e2c28038  Image Info:     e2c2a1e4 Subsection 1. @ 8119b640    ControlArea: 8119b608  Starting Sector 0 Number Of Sectors 8    Base Pte     e2c28038   Ptes In subsect    1 Unused Ptes                0    Flags              15   Sector  Offset     0 Protection                 1     ReadOnlyCopyOnWrite Subsection 2. @  8119b660    ControlArea:  8119b608  Starting Sector 10 Number Of Sectors 3c00    Base Pte      e2c2803c  Ptes In subsect      780 Unused Ptes            0    Flags               35  Sector  Offset         0 Protection             3     Read Only CopyOnWrite Subsection 3. @  8119b680    ControlArea:  8119b608  Starting Sector 3C10 Number Of Sectors 5d8    Base Pte      e2c29e3c  Ptes In subsect       c1 Unused Ptes            0    Flags               55  Sector Offset          0 Protection             5     Read Only CopyOnWrite Subsection 4. @  8119b6a0    ControlArea:  8119b608  Starting Sector 41E8 Number Of Sectors a8    Base Pte      e2c2a140  Ptes In subsect       15 Unused Ptes            0    Flags               55  Sector Offset          0 Protection             5     Read Only CopyOnWrite Subsection 5. @  8119b6c0    ControlArea:  8119b608  Starting Sector 0 Number Of Sectors 0    Base Pte      e2c2a194  Ptes In subsect        1 Unused Ptes            0    Flags               55  Sector Offset          0 Protection             5     Read Only CopyOnWrite Subsection 6. @  8119b6e0    ControlArea:  8119b608  Starting Sector 4290 Number Of Sectors 90    Base Pte      e2c2a198  Ptes In subsect       12 Unused Ptes            0    Flags               15  Sector Offset          0 Protection             1     Read Only CopyOnWrite