MMWSL

The MMWSL is the Memory Manager’s modelling of a Working Set List. Every working set, as modelled by an MMSUPPORT, has one: it’s pointed to from the latter’s VmWorkingSetList member.

Availability

Windows was born with the notion of working sets for the management of virtual address space. All known versions have the MMWSL structure, but the 1607 edition of Windows 10 renames it as MMWSL_FULL. This comprises new MMWSL_INSTANCE and MMWSL_SHARED structures which each have a different selection of the old MMWSL members.

Some measure of the MMWSL structure’s importance in memory management is that it’s one of the few structures (in contrast to mere arrays of small types) that Windows builds at a preset address. Through much of the history of Windows, every process has its working set’s MMWSL at the same address:

The early 32-bit builds, both with and without support for Physical Address Extension (PAE), access the current process’s MMWSL through an internal variable named MmWorkingSetList which is initialised to this fixed address and is thereafter left alone. Versions 5.1 and 5.2 can vary this variable’s initialisation by 0x00000800 when a virtual bias applies, as for the /3GB boot option. Starting with version 6.1, the variable is discarded in favour of hard-coding the address. All known 64-bit kernels that have the structure hard-code the address.

Whether the predictability of this address for the MMWSL was ever exploitable is not known, but the 1703 release of Windows 10 does away with it.

Variability

As an internal structure with little, if any, visibility outside the kernel, the MMWSL varies greatly between versions and even between builds:

Layout

The preceding sizes, and the names, offsets and types in the tables that follow, are from Microsoft’s symbol files for the kernel, starting with Windows 2000 SP3. What little information is given below for earlier versions—even for early builds of version 5.0—is at best tentative. What’s known of Microsoft’s names and types for these versions is something of a guess. Where use of a member corresponds closely with that of a version for which Microsoft’s symbols are available, it seems reasonable to suppose continuity. Some use, however, has no correspondence, the code having changed too much. Even where the use hasn’t changed, tracking it down exhaustively would be difficult, if not impossible, even with source code—and I haven’t yet tried to track it down exhaustively.

For many of the integral members, the value is a 0-based index into an array of MMWSLE structures. This index was widened from 32 bits to 64 for 64-bit Windows 8.1. Microsoft almost certainly defines a type for this index. The KDEXTS.DLL debugger extension confirms with high confidence that Microsoft’s name for this type is WSLE_NUMBER. For the table below, WSLE_NUMBER is ordinarily a ULONG but is a ULONG_PTR in 64-bit Windows version 6.3 and higher.

ULONG Quota;

WSLE_NUMBER FirstFree;

WSLE_NUMBER FirstDynamic;

WSLE_NUMBER LastEntry;

WSLE_NUMBER NextSlot;

MMWSLE *Wsle;

PVOID LowestPagableAddress;

ULONG NumberOfCommittedPageTables;

WSLE_NUMBER LastInitializedWsle;

WSLE_NUMBER NextEstimationSlot;

WSLE_NUMBER NextAgingSlot;

WSLE_NUMBER NextAccessClearingSlot;

ULONG LastAccessClearingRemainder;

ULONG LastAgingRemainder;

ULONG WsleSize;

ULONG EstimatedAvailable;

ULONG GrowthSinceLastEstimate;

ULONG NumberOfCommittedPageTables;

ULONG VadBitMapHint;

WSLE_NUMBER NonDirectCount;

MMWSLE_HASH *HashTable;

ULONG HashTableSize;

KEVENT *ImageMappingPteEvent;

KEVENT ImageMappingPteEvent;

ULONG NumberOfCommittedPageTables;

ULONG LastVadBit;

ULONG MaximumLastVadBit;

ULONG LastAllocationSizeHint;

ULONG LastAllocationSize;

PVOID LowestPagableAddress;

MMWSLE_NONDIRECT_HASH *NonDirectHash;

PVOID HashTableStart;

MMWSLE_HASH *HashTableStart;

PVOID HighestPermittedHashAddress;

MMWSLE_HASH *HighestPermittedHashAddress;

ULONG NumberOfImageWaiters;

ULONG VadBitMapHint;

PVOID HighestUserAddress;

The x86 builds of versions before version 6.2 end with arrays whose sizes vary with how many page tables can be needed for the whole of the user-mode address space. Description is eased by hypothesising MAX_USER_PAGE_TABLES as a symbolic name for this number:

• 0x0200 before version 5.0;
• 0x0300 in version 5.0 and higher without PAE;
• 0x0600 in version 5.0 and higher with PAE.

USHORT UsedPageTableEntries [0x0400];

USHORT UsedPageTableEntries [MAX_USER_PAGE_TABLES];

ULONG CommittedPageTables [MAX_USER_PAGE_TABLES / 0x20];

The x64 builds of versions before 6.2 end very differently. The one member in common with the x86 builds is CommittedPageTables, but it is a pointer, not an array.

ULONG MaximumUserPageTablePages;

ULONG MaximumUserPageDirectoryPages;

ULONG *CommittedPageTables;

ULONG NumberOfCommittedPageDirectories;

ULONG *CommittedPageDirectories;

ULONGLONG CommittedPageDirectories [0x80];

ULONG NumberOfCommittedPageDirectoryParents;

ULONGLONG CommittedPageDirectoryParents [1];

Added For Windows 8  

ULONG ActiveWsleCounts [8];

ULONG_PTR ActiveWsleCounts [8];

ULONG_PTR ActiveWsleCounts [0x10];

MI_ACTIVE_WSLE ActiveWsles [8];

MI_ACTIVE_WSLE_LISTHEAD ActiveWsles [8];

MI_ACTIVE_WSLE_LISTHEAD ActiveWsles [0x10];

MMWSLE *Wsle;

MI_USER_VA_INFO UserVaInfo;