SECTION

The SECTION structure (formally _SECTION) is the kernel’s representation of a section object. Both kernel-mode and user-mode software may obtain a handle to a section object. Kernel-mode software may reference the handle to obtain the address of the object. If the ObReferenceObjectByHandle function successfully resolves a handle though directed to do so only if the object type is MmSectionObjectType, then the pointer that the function produces for the object is a pointer to a SECTION.

Documentation Status

The SECTION structure is not documented. Microsoft is not known to have disclosed even its name for—let alone any internal details of—whatever kernel-mode structure supports a handle to a section object. For the handful of exported functions, e.g., MmMapViewInSystemSpace and MmMapViewInSessionSpace, that take a pointer to a section object as an argument and for which Microsoft has published C-language declarations in headers from a Windows Driver Kit (WDK), the argument’s type is simply PVOID. Even the referencing of the object from a handle is obscure: though the MmSectionObjectType variable is a kernel export as far back as version 3.51, it never has been declared in any WDK header except an NTOSP.H that Microsoft disclosed in early editions of the WDK for Windows 10 (apparently only by oversight).

The structure of a section object is obscure even in the public symbol files. Before the original Windows 10, these show type information for a SECTION_OBJECT but not for the SECTION.

Layout

The SECTION is 0x28 and 0x40 bytes in 32-bit and 64-bit Windows, respectively, in all known versions. Sizes, types and Microsoft’s names of members are from public symbol files for the Windows 10 kernel. What is shown below for earlier versions is, of course, something of a guess.

PVOID StartingVa;

PVOID EndingVa;

PVOID Parent;

PVOID LeftChild;

PVOID RightChild;

MM_AVL_NODE SectionNode;

RTL_BALANCED_NODE SectionNode;

PVOID StartingVa;

ULONG_PTR StartingVpn;

PVOID EndingVa;

ULONG_PTR EndingVpn;

SEGMENT *Segment;

union {
    CONTROL_AREA *ControlArea;
    FILE_OBJECT *FileObject;
    struct {
        RemoteImageFileObject : 1;
        RemoteDataFileObject : 1;
    };
} u1;

The original behaviour is consistent with the section object beginning as a SECTION_OBJECT, which is well known from symbol files, but continuing with members that symbol files for Windows 10 confirm are those of the SECTION (see below). The SECTION_OBJECT can usefully be seen as having its members in three sets: two for the virtual addresses of the section’s first and last bytes; three as links for the section object in a tree; a pointer to a SEGMENT. The kernel for Windows Server 2003 swaps the first two but the symbol files for the SECTION_OBJECT show no such reordering. This means that for whatever reason the SECTION_OBJECT survives in symbol files in version 5.2—indeed, all the way to the original Windows 10—it cannot be that the SECTION_OBJECT any longer had anything to do with section objects as actually implemented by the kernel.

In Windows 10, the section object ordinarily keeps a pointer to the control area, which has in its turn a FilePointer for access to the file. However, if the file’s device object has the FILE_REMOTE_DEVICE characteristic, then the section object instead keeps a pointer to the file object. In this case, one or other of the low two bits in the address is set according to whether the section is for an image or for data. The control area is then found through the file object’s SectionObjectPointer.

ULONGLONG SizeOfSection;

union {
    ULONG LongFlags;
    MMSECTION_FLAGS Flags;
} u;

ULONG InitialPageProtection;

struct {
    /*  changing bit fields, see below  */
};

The InitialPageProtection comes from the macros (defined in WDM.H and WINNT.H) that start with PAGE_NOACCESS. It will typically be just what was provided as the SectionPageProtection argument when creating the section, but PAGE_NOCACHE and PAGE_WRITECOMBINE bits can have been picked up by implication. The point to retaining it in this form is for validating that the Win32Protect argument that is presented when later mapping a view of the section is compatible with the page protection that was specified for the section.

Windows Vista recognised that with only 12 bits allowed for the InitialPageProtection, a truly new member could be added to the SECTION without changing the size:

ULONG InitialPageProtection : 12;

ULONG SessionId : 20;

ULONG SessionId : 19;

ULONG NoValidationNeeded : 1;