MMPFN Union 4

The MMPFN (Memory Manager Page Frame Number) structure is the key to pretty much everything that the Memory Manager knows about a page of physical memory that is in general use. Since an array of these structures for all physical memory needs to be kept in physical memory, the MMPFN is its own substantial overhead. Presumably to keep this down, ever more gets packed in to the MMPFN ever more intricately.

That space is tight in the MMPFN is demonstrated well by the very last of its fields. Its location within the MMPFN is the same in all versions:

Also in all versions, the largest part of this last field is the PteFrame. This is the Page Frame Number (PFN) of what the !pfn command names the “containing page”. For the physical page that is described by an MMPFN to be addressable, the page’s physical address must be discoverable from at least one Page Table Entry (PTE) in some page table. This page table is also a physical page. One such page is distinguished as the containing page. Its PFN is the contained page’s PteFrame.

For the earliest versions, the PFN is only 20 bits which leaves 12 for other use. Space was tight already, and all 12 other bits were put to use. Versions 3.10 to 3.51 hold the PteFrame in something like the form of a PTE, i.e., with the PFN in the high 20 bits and bit flags in the low 12, all presumed here to have been packaged as an early form of what public symbol files later present as an MMPFNENTRY structure. When version 4.0 recovered space by narrowing a 32-bit ReferenceCount at offset 0x0C to 16 bits, the flags were moved to this new space and the PteFrame was left alone as the whole of its dword.

Still, this left 12 unused bits at offset 0x14. Pressure on space soon found use for them. When version 5.1 squeezed in two new bit fields, now as high bits, opportunity was taken to package the lot with the PteFrame and new (and future) bit fields in a union with an integral EntireFrame. See that the bit flags have nothing to do with any frame of any containing page: the frame in the name is just historical. Version 6.0 did away with it, so that u4 holds just the bit flags in an unnamed structure in the unnamed union. Version 6.2 restores access to the whole as an integral type but now with the arguably better name EntireField.

ULONG_PTR EntireFrame;

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

ULONG_PTR EntireField;

While 32-bit and 64-bit Windows need deal only with 36-bit and 48-bit physical addresses, the PFN of a physical page does not need the whole ULONG or ULONGLONG that Microsoft defines for the PFN_NUMBER. Wherever a physical page number is kept in anything that’s similar to a PTE, there are always the low 12 bits for flags. What’s left for a PFN is at most 20 or 52 bits in a 4-byte or 8-byte PTE, respectively. In 64-bit Windows, and in 32-bit Windows with PAE, the paging algorithm does not (yet) support a 52-bit physical address space. Instead, a PFN can be at most 20 bits for 32-bit Windows without PAE, 24 bits for 32-bit Windows with PAE and 36 bits for 64-bit Windows. This leaves many bits for use in any container of a PFN. Finding such use in the MMPFN member that holds the particular PFN that’s named PteFrame is the reason that the u4 exists. The original name, PteFrame, survives just as the first of the chaning bit fields in u4. Its width took some time to settle:

See that the progressive reduction in what to allow has been more about the need for creating space somewhere in the MMPFN (both here and in u1 and especially in u2) than about codifying the width that’s implied by 36-bit and 48-bit physical address spaces. The effective width of a PFN in u4 is represented below as PFN_BITS.

ULONG_PTR PteFrame : PFN_BITS;

ULONG_PTR Channel : 2;

ULONG_PTR LargePageSize : 2;

ULONG_PTR Unused1 : 1;

ULONG_PTR Unused2 : 1;

ULONG_PTR Partition : 10;

ULONG_PTR Unused : 3;

ULONG_PTR Unused : 16;

ULONG_PTR Unused3 : 13;

ULONG_PTR Spare : 2;

ULONG_PTR FileOnly : 1;

ULONG_PTR PfnExists : 1;

ULONG Spare : 8;

ULONG_PTR PfnImageVerified : 1;

ULONG_PTR ModifiedListBucketIndex : 2;

ULONG_PTR PageIdentity : 2;

ULONG_PTR PageIdentity : 3;

ULONG_PTR InPageError : 1;

ULONG_PTR VerifierAllocation : 1;

ULONG_PTR AweAllocation : 1;

ULONG_PTR PrototypePte : 1;

ULONG LockCharged : 1;

ULONG KernelStack : 1;

ULONG_PTR Priority : 3;

ULONG_PTR MustBeCached : 1;

ULONG_PTR PageColor : 4;

ULONG_PTR PageColor : 6;

ULONG Reserved : 4;

ULONG Reserved : 1;

Several of the bit fields move between this union and the MMPFNENTRY structure:

• InPageError moved here for version 5.1 and moved back in 6.0;
• VerifierAllocation moved here for version 5.1 and was discontinued in 6.0;
• LockCharged is in both in late 5.1, is only here in 5.2, and was discontinued in 6.0;
• KernelStack started here in late 5.1 and moved out in 6.0;
• Priority started here in late 5.2 and moved out in 6.0;
• PrototypePte moved here for version 6.0 and remains;
• PageColor moved here for version 6.0 and was discontinued in Version 2004.

The ModifiedListBucketIndex is new to this union in the 32-bit Windows 10 Version 2004 but the 64-bit build has it as 4 bits at offset 0x27 in the MMPFN.