Resolving Windows 2000/XP Process Working Set

In "Resolving Windows 2000/XP Physical Memory Management", I introduced the concept of Page Frame Database in detail, referring to the organization and management of physical memory. For each page system, a structure is saved in the page frame database for tracking page status and so on. But the page frame database does not really coordinate the use of physical memory. We know that Windows is a multi-tasking, and physical memory is a relatively scarce resource. To avoid a process (or system) running out of this resource, the concept of WorkingSet is introduced. WorkingSet is a very important term for memory management. In Windows 2000/XP, there are usually two types of process working sets and system working sets, which are used to track the physical memory usage of each process and system. Due to the introduction of Terminal Services, there is also a working set Session working set for tracking the use of physical memory by each Session. This paper starts from the internal organization of the process work set, and briefly describes the organization and management of the work set in Windows 2000/XP.

EPROCESS is a description of the structure of the process, so starting with EPROCESS, you can certainly find the representation of the process working set. In fact, the sub-structure MMSUPPORT located in EPROCESS is some key content related to the process and memory subsystem, and the process working set is naturally also here. For the early kernel version, these contents are not integrated into the MMSUPPORT structure, and the definition of MMSUPPORT is different between versions. The definition of MMSUPPORT in Windows XP Build 2600 SP0 is listed below (all structures in this article may only be applicable to this. version):

typedef struct _MMSUPPORT {
LARGE_INTEGER LastTrimTime;
MMSUPPORT_FLAGS Flags;
ULONG PageFaultCount;
ULONG PeakWorkingSetSize;
ULONG WorkingSetSize;
ULONG MinimumWorkingSetSize;
ULONG MaximumWorkingSetSize;
PMMWSL VmWorkingSetList;
LIST_ENTRY WorkingSetExpansionLinks;
ULONG Claim;
ULONG NextEstimationSlot;
ULONG NextAgingSlot;
ULONG EstimatedAvailable;
ULONG GrowthSinceLastEstimate;
} MMSUPPORT, *PMMSUPPORT;

PeakWorkingSetSize, WorkingS in MMSUPPORT etSize, MinimumWorkingSetSize, and MaximumWorkingSetSize represent the working set peak, the working set size, and the maximum and minimum values ​​of the allowed working set, respectively, for this process. Both the performance monitor (perfmon.msc) and the task manager (taskmgr.exe) can track these data processes. Win32 API GetProcessWorkingSetSize(Ex) and SetProcessWorkingSetSize(Ex) can get or set MinimumWorkingSetSize and MaximumWorkingSetSize after having the corresponding PROCESS_QUERY_INFORMATION and PROCESS_SET_QUOTA permissions.

When the process is established, the process work set is always empty, and CreateProcess is responsible for initializing the process work set during the process of establishing the process. It allocates a physical page and then calls MiInitializeWorkingSetList to initialize the process working set. The latter initializes the MMSUPPORT structure we mentioned above with the newly created EPROCESS as a parameter. Here is a very important member VmWorkingSetList (structure MMWSL), defined as follows:

+0x000 Quota : Uint4B
+0x004 FirstFree : Uint4B
+0x008 FirstDynamic : Uint4B
+0x00c lastEntry: Uint4B
+ 0x010 NextSlot: Uint4B
+ 0x014 Wsle: Ptr32 _MMWSLE
+ 0x018 LastInitializedWsle: Uint4B
+ 0x01c NonDirectCount: Uint4B
+ 0x020 HashTable: Ptr32 _MMWSLE_HASH
+ 0x024 HashTableSize: Uint4B
+ 0x028 NumberOfCommittedPageTables: Uint4B
+ 0x02c HashTableStart: Ptr32 Void
+ 0x030 HighestPermittedHashAddress: Ptr32 Void
+ 0x034 NumberOfImageWaiters: Uint4B
+ 0x038 VadBitMapHint: Uint4B
+ 0x03c UsedPageTableEntries : [768] Uint2B
+0x63c CommittedPageTables : [24] Uint4B

For efficiency reasons, Windows 2000/XP maps this structure to a fixed virtual memory address. It is specified by the kernel variable MmWorkingSetList. In fact, MiInitializeWorkingSetList directly refers to this variable to operate on the VmWorkingSetList member of the MMSUPPORT structure. MmWorkingSetList is located in the kernel area (0xc0503000 in Windows XP Build 2600 Professional). Usually the kernel area is shared by all processes, but obviously the WorkingSet specified by MmWorkingSetList has different mappings for each process, that is, it has different content. This is the same as the process page directory or the page table. The latter I have done a detailed test in the "Small Windows NT/2000 paging mechanism".

Because the process WorkingSet is used to describe the process using physical memory, in other words, the pages in the WorkingSet are located in physical memory (not replaced by pagefile.sys), so access to these pages is not Will cause a Page Fault. We can use VirtualLock to place pages into the process work set. Conversely, how does the system know a page (using a virtual page address), is there a work center for this process? A cursory look at the definition of MMWSL given above, you know that Windows 2000/XP uses a hash table to organize these pages. HashTable has the characteristics of fast retrieval, which is suitable for the frequent access of WorkingSet. Another example is the organization of the system global naming kernel, as described in "Analysis of Windows NT/2000 Kernel Object Organization." Like Windbg's !object command, which provides dump global command kernel objects, Windbg provides !wsle for the dump process working set. For example:

kd & gt; wsle 7

Working Set @ c0503000
FirstFree:! 469 FirstDynamic: 7
LastEntry 46c NextSlot: 4 LastInitialized 658
NonDirect 145 HashTable: c06f4000 HashTableSize: 400

Reading the WSLE data ...
..
Virtual Address Age Locked ReferenceCount
c0300203 0 1 1
c0301203 0 1 1
c0502203 0 1 1
c0503203 0 1 1
c0504203 0 1 1
c06f4203 0 1 1
c06f5203 0 1 1
c0505203 0 1 1
c0506203 0 1 1
77c47029 0 0 1 < BR> .
.
.