在《解析Windows 2000/XP物理内存管理》中我详细的介绍了页框数据库(Page Frame Database)的概念，提到在物理内存的组织与管理方面对于每个页面系统都在页框数据库中保存一个结构，用于跟踪页面状态等。但页框数据库并不能真正协调物理内存的使用。我们知道，Windows是一个多任务的操作系统，而物理内存却是一个相对贫乏的资源，为避免某个进程(或是系统)耗尽这一资源，引入了工作集(WorkingSet)的概念。WorkingSet是内存管理一个相当重要的术语，在Windows 2000/XP中通常分为两种即进程工作集与系统工作集，分别用于跟踪各个进程与系统的物理内存使用情况。由于终端服务的引入，另有一种工作集会话(Session)工作集，用于跟踪各个Session使用物理内存的情况。本文从进程工作集的内部组织方式出发，简要阐述工作集在Windows 2000/XP中的组织与管理。
EPROCESS是描述进程的结构，所以从EPROCESS入手，肯定也能找到进程工作集的表示方式。实际上位于EPROCESS中的子结构MMSUPPORT就是关于进程与内存子系统相关的一些关键内容，进程工作集自然也在此。对于早期的内核版本这些内容没有集成至MMSUPPORT结构中，而且各版本间MMSUPPORT的定义是不相同的，底下列出MMSUPPORT在Windows XP Build 2600 SP0中的定义(本文中所有结构都可能只适用于这一版本)：
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;
MMSUPPORT中PeakWorkingSetSize、WorkingSetSize、MinimumWorkingSetSize与MaximumWorkingSetSize分别表示此进程的工作集峰值、当然工作集大小、允许工作集的最大值与最小值。性能监视器(perfmon.msc)与任务管理器(taskmgr.exe)都可对这些数据进程跟踪显示。Win32 API GetProcessWorkingSetSize(Ex)和SetProcessWorkingSetSize(Ex)在具有相应PROCESS_QUERY_INFORMATION与PROCESS_SET_QUOTA权限后即能获取或设置MinimumWorkingSetSize与MaximumWorkingSetSize等。
进程在建立时，进程工作集总为空的，CreateProcess等在建立进程过程中有责任初始化进程工作集。它会分配一个物理页面，然后调用MiInitializeWorkingSetList初始化进程工作集。后者以刚建立的EPROCESS作为参数初始化我们上面提到的MMSUPPORT结构。这里要提到一个很重要的成员VmWorkingSetList(结构MMWSL)，定义如下：
+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
效率上考虑，Windows 2000/XP均将这一结构映射至一固定的虚拟内存地址中。由内核变量MmWorkingSetList指定，实际上MiInitializeWorkingSetList就是直接引用这个变量对MMSUPPORT结构的VmWorkingSetList成员进行操作的。MmWorkingSetList位于内核区域(在Windows XP Build 2600 Professional中为0xc0503000)，通常内核区域均是由所有进程共享的，但显然MmWorkingSetList指定的WorkingSet情况对于每个进程都有不同的映射，即具有不同的内容，这与进程页目录或是页表一样。后者我在《小议Windows NT/2000分页机制》中详细的做过测试。
因为进程WorkingSet是用于描述进程使用物理内存的情况，换句话说位于WorkingSet中的页面均位于物理内存中(没有被置换到pagefile.sys中等)，所以访问这些页面均不会导致Page Fault。我们可以使用VirtualLock将页面置入进程工作集中。反过来想，系统如何知道某一页面(使用虚拟页面地址)，针对这一进程是否存在于工作集中呢？粗粗浏览一下上面给出的MMWSL的定义，就知道Windows 2000/XP使用哈希表(HashTable)来组织这些页面。HashTable具有快速检索的特点，正好适合于WorkingSet频繁访问的特点。另一个例子是系统全局命名内核的组织，详见《剖析Windows NT/2000内核对象组织》。与Windbg提供dump全局命令内核对象的!object命令一样，Windbg提供!wsle用于dump进程工作集。例如：
kd> !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
.
.
.
wsle命令只是将VmWorkingSetList的Wsle成员(MMWSLE指针)指向的数组的每个元素dump出(每个元素32bit)。windbg的!wsle命令获得的结果中Virtual Address列即Wsle的每一个32bit的内容。如下windbg命令所示：
kd> dd MmWorkingSetList l 1 //当前进程MMWSL结构所在的地址，如本文前头描述。
805467d0 c0503000
&nb
