Windows采用页式内存管理方案，在Intel x86处理器上，Windows不适用段来管理虚拟内存，但是，Intel x86处理器在访问内存时必须要通过段描述符，这意味着Windows将所有的段描述符都构造成了从基地址0开始，且段的大小根据段的用户和系统设置的不同，会设置为0x80000000，0xC0000000或0xFFFFFFFF。所以，Windows系统中的代码，包括操作系统本身的代码和应用程序的代码，所面对的地址空间都是线性地址空间。这种做法相当于屏蔽了处理器中的逻辑地址概念，段只被用于访问控制和内存保护。

Windows使用了两种特权级别：0和3，其中特权级0称为内核模式，特权级3称为用户模式。当处理器指向内核模式代码时，它们处于系统地址空间，位于0x80000000~0xFFFFFFFF，所有的进程共享此空间；当处理器执行用户模式代码时，它们处于进程地址空间，位于0x00000000~0x7FFFFFFF，这部分空间是进程私有的。用户模式代码只能访问进程自身的数据，而内核模式代码不仅可以访问当前进程的数据，也可也访问系统地址空间中的数据。所有的进程，一旦进入到内核模式，则共享同一的系统地址空间。

在Windows的每个地址空间中，虚拟地址的分配和回收都必须按照规定执行。Windows规定，应用程序在使用内存以前必须先申请，所以，操作系统内部可以根据应用程序的申请和释放操作来维护好整个虚拟地址空间的内存分配情况。而且，Windows也采用了按需分配的策略，也就是说，只有当一段虚拟地址空间真正被使用的时候，系统才会为它分配页表和物理页面。每个进程的虚拟地址空间的分配情况通过一组虚拟地址描述符（VAD）记录下来，这些描述符构成了有一颗平衡二叉树，以便于快速地定位到一个指定虚拟地址地描述符上。

在系统地址空间中，有些部分提供一些特殊模块使用，比如会话空间是由会话管理器和Windows子系统使用的；而换页内存池和非换页内存池则是提供给系统内核模块和设备驱动程序使用的。在换页内存池中分配的内存有可能在物理内存紧缺的情况瞎被换出到外存中；而非换页内存池中分配的内存总是处于物理内存中。为了实现这两种池，Windows使用了两层内存管理。下层是基于页面的内存管理，仅限于执行体内部使用；上层建立在下层的内存管理功能基础之上，对外提供各种粒度的内存服务。两层结果如下图所示

系统换页内存池和非换页内存池是Windows系统提供的最基本动态内存管理手段，它以页面为基本粒度来管理系统中划定的地址范围。

页面粒度对于一般的代码逻辑而言太大了。所以，为了适应各种内核组件对于内存管理的需要，Windows内核在系统的非换页内存池和换页内存池的基础上，实现了灵活的，可适应各种大小内存需求的内存池，这便是执行体内存池。

执行体内存对象是由数据结构POOL_DESCRIPTOR来描述的，定义如下：

以下是WRK中和内存管理有关的一部分全局变量:

ExpNumberOfNonPagePools代表非换页内存池数量，只有一个；而换页内存池的数量，即变量ExpNumberOfPagedPools，在单处理器系统上是3个，在多处理器系统上有5个。PoolVector是一个包含两个数组的元素，第一个元素PoolVector[0]指向非换页内存池，即NonPagedPoolDescriptor的地址；第二个元素PoolVector[1]指向换页内存池，即指向第一个换页内存池。数组ExpNonPagedPoolDescriptor仅用于有多个非换页内存池的情形；数组ExpPagedPoolDescriptor中的每个元素分别指向一个换页内存池。

执行体内存池对象的初始化是按照换页内存池和非换页内存池分开进行的，在Windows系统内核中通过一些列内核函数来使用内存池对象。

执行体内存池的初始化是在InitializePool函数中完成的，函数首先会判断要初始化的内存池是否是非分页内存池

如果要初始化非分页内存池，就会判断KeNumberNodes中的数据是否大于1，根据后面代码的内容可推测这个变量保存的是处理器的核数

如果大于1，就会修改全局变量ExpNumberOfNonPagedPools保存的数据

调用ExInitializePoolDescriptor来初始化非分页内存池对象，该内存池对象的地址则是全局变量NonPagedPoolDescriptor，且在初始化之前会将地址保存到PoolVector数组中的第一个元素

如果要初始化分页内存池，首先依然会判断KeNumberNodes中保存的数据是否大于1

如果大于1，则修改ExpNumberOfPagedPools中保存的数据

调用函数来申请一块内存，由于此时ebx等于0，所以申请的是非分页内存，而申请的内存的大小则是ExpNumberOfPagedPools的大小加1乘以0x1048的大小

这里申请的内存大小之所以要乘以0x1048，是因为要保存的结构体除了内存池对象的0x1028字节大小，还要申请FAST_MUTEX对象的0x20大小，该对象结构体如下：

将内存池对象地址赋给PoolVector数组下标为1的地址，将FAST_MUTEX对象地址赋给全局变量ExpPagedPoolMutex，并将参数PoolType修改为0，因为此时ebx等于0

将填充申请到的ExpNumberOfPagedPools+1个的内存池对象和FAST_MUTEX对象

因此，可以得出结论，分页内存池对象也是用非分页内存来保存的。而无论是初始化非分页内存对象还是初始化分页内存对象，都需要通过ExInitializePoolDescriptor函数来实现

ExInitializePoolDescriptor函数首先对对象中的前几个成员赋值

此时eax是内存池对象地址，加上0x28就会获得ListHeads成员的地址，而该成员是一个双向链表的数组，共有512个元素，所占内存大小为0x1000，所以接下来就是将ListHeads中的每一个双向链表都指向自己

为了管理内存的开销，每次通过执行体内存池分配的内存块有8字节大的POOL_HEADER结构体，该结构体定义如下：

这里的PreviousSize和BlockSize都是指实际大小除以8之后得到的值，并非原始值

POOL_DESCRIPTOR对象中的ListHeads成员维护了一组快表，这些快表包含了8字节倍数大小的空闲内存块链表。虽然ListHeads有512个成员，但是由于最小的内存块是8个字节，且POOL_HEADER也是8个字节，所以，实际使用的只有510项，分别对应于8，16，... ，4072和4080大小的空内存块。如果申请的内存块大小在4080到4096之间，就会使用整个页面，因为剩下的空间不足以容纳最小内存块（8字节）加上管理开销（8字节）。下图显示了执行体内存池对象的管理结构：

通常用户会使用ExAllocateTag或者ExAllocateTagEx来申请内存，但是真正申请内存的其实是函数ExAllocateTagEx，因为前者是通过调用后者来实现的

在函数ExAllocatePoolEx中，首先会通过PoolType从PoolVector中取出相应的内存池对象,局部变量则用来记录申请的情况

通过参数NumberOfBytes判断申请的内存大小是否是大于0xFF0的大页面，如果是大页面就会直接通过调用函数MiAllocatePoolPages来直接申请内存块，此时的内存地址按页对齐，也就是地址的低12位为0

如果不是大页面，判断NumberOfBytes为0，则假设为1字节，因为有些驱动在分配的时候会设置为0，根据要申请的内存NumberOfBytes计算在快表ListHeads数组中的索引，即ListNumber局部变量

对于申请分页内存情况，根据情况ListNumber是否是小于0x20的小页面内存来决定是要从处理器的后备链表中分配内存，还是通过全局变量ExpPagedPoolDescriptor保存的分页池对象分配内存

对于申请非分页内存情况，根据变量var_PoolType与NeedSize来决定是否要从处理器的后备链表中来分配内存，还是从全局变量ExpNonPagedPoolDescriptor中获取非分页内存对象来分配内存

如果是要在非分页内存对象中申请内存，最后会跳转到上面使用分页内存对象来申请内存时候的LABEL_17执行，而LABEL17则跳转到LABEL_18执行剩下的代码

剩下的代码就是先从链表中寻找内存块，如果没有找到可用的内存块，那么就会通过调用函数MiAllocatePoolPages来申请新的内存块，而多申请的内存块也会被加入到链表中，而内存块链接进链表的位置是POOL_HEADER以后的八字节，也就是说池对象头后就是用来链接进链表的双向链表，以下是WRK中关于这部分内容的部分代码：

因此，可得出ExAllocatePoolWithTag函数基本流程如下：

如果申请的是大页面，直接调用MiAllocatePoolPages分配池内存

如果请求小页面，尝试从当前处理器控制块后备链表分配

如果后备链表分配失败，在从PoolVector指向的池描述符512条链表中分配

如果池描述符链表分配也失败，在调用MiAllocatePoolPages分配

池内存的释放是通过ExFreePool来实现的，函数首先会判断要释放的池内存是否是大页面内存，由于大页面内存的地址是按页对齐的，低12位为0，所以此时如果与0xFFF与运算以后的结果为0，则说明是大页面池内存

对于大页面池内存，会通过MiFreePoolPages来释放

和申请池内存类似，如果释放的是小页面池内存，就会尝试将池内存交还给当前处理器控制块的后备链表

如果不是上面的两种情况，函数就会判断要释放的内存块的上一内存块和下一内存块是否在被使用中，如果没有被使用，就会将它们合并成为一个内存块。合并的内存块如果刚好一个页的大小，函数就会调用MiFreePoolPages释放内存，否则的话就会将其加入到链表中

相比于高2GB每个进程共享的内核内存空间，低2GB的用户内存空间则是每个进程独立拥有的内存空间。也就是说，这部分空间只能由进程自己访问，其他进程无法访问。Windows系统在进程切换的时候，通过更换页目录表基址，也就是CR3寄存器中的内容来实现每个进程独享其高2GB的内存空间。高2GB的内存空间还根据地址分成了不同的分区，如下是32位系统的不同地址的分区情况

对于进程地址空间，用户程序必须经过“保留(reserve)”和"提交(commit)"两个阶段才可以使用一段地址范围。“保留一段地址范围”的用意是，将这段地址范围保留起来，但并不真正使用，由于这段地址范围不占用任何物理内存或其他外存空间，所以并不会形成实质的开销。这对于有些需要连续地址空间的程序有意义，它们可用在初始时保留一段大地址范围，以后需要的时候陆续使用。提交地址范围是指这段地址终究要消耗物理内存，由于Windows支持物理内存和页面文件之间的交换，因此可提交的内存数量是，可用物理内存总量去除系统使用的物理内存数量后，在加上页面文件的大小

在已提交的地址范围中，当页面被访问时，一定要先映射到物理内存页面上。这些页面要么是一个进程私有的，不共享的，要么被映射到一个内存区的视图上。后者可被多个进程共享

在Windows提供的API中，VirtualAlloc或VirtualAllocEx被用来保留或提交地址范围，通过这两个API申请的内存就是私有内存，只有申请内存的进程可使用；之后可用通过VirtualFree或VirtualFreeEx函数来解除已提交的地址范围，或者完全释放此地址范围。解除提交是指回到保留状态。因此，对于进程地址空间中的任何一个页面的地址范围，它一定处于三种状态之一：空闲的，保留的，或已提交的

以VirtualAllloc函数为例，该函数的定义如下：

其中第三个参数flAllocationType指定了申请的进程内存地址是“保留“或是”提交“。当该参数是MEM_RESERVE的时候，申请的进程内存地址是”保留“的，当参数为MEM_COMMIT的时候，申请的进程内存地址就是”提交“的

共享内存是通过创建内存区对象来实现的，内存区对象是Windows平台上多个进程之间共享内存的一种常用方法，它可被映射到系统的页面文件或其他文件中。实际上，内存区对象代表了一种物理存储资源，它可能在物理内存中，也可能在系统页面文件中，或其他文件中

内存区对象有两种，一种建立在页面文件的基础上，称为页面文件支撑的内存区，另一种被映射到其他文件中，称为文件支撑的内存区，也称为文件对象

Windows提供的CreateFileMapping这个API就是用来创建内存区对象的，该函数定义如下：

当第一个参数传入INVALID_HANDLE_VALUE（宏定义，值为-1）的时候，就会创建一个页面文件支撑的内存区，最后一个参数则指定了内存区的名称。当其他进程想要使用该内存区的时候，就可使用如下定义的OpenFileMapping函数，通过第三个参数lpName来打开指定的内存区

获取指定内存区的句柄以后，就可通过MapViewOfFile函数来将物理地址映射到用户空间中

Windows的进程地址空间是通过VAD（虚拟地址描述符）来管理的。VAD对象描述了一段连续的地址范围。在整个地址空间中，保留的或提交的地址范围有可能是不连续的，所以，Windows使用一颗平衡二叉搜索树（称为AVL树）来管理VAD对象。在进程内核对象EPROCESS偏移0x11C处保存的VadRoot域指向的就是此树的根。该树的每一个节点的对象结构体是MMVAD，定义如下：

其中的MMVAD_FLAGS结构体定义如下：

以记事本进程为例，通过查看EPROCESS结构的VadRoot就可得到该进程VAD对象的二叉树的根节点地址，此时为0x81D14F48

根据VadRoot的地址就可找到相应的树的根，通过其左右子树就可遍历这颗二叉树

也可查看该VAD对象的内存属性

为了方便查看一个进程的内存使用情况，WinDbg提供了vad命令来解析这颗二叉树，如下就是对记事本进程的内存使用情况

在系统地址空间，有一个区域称为PFN数据库，用于管理系统的物理内存。PFN数据库是一个阵列，或者说是一个数组，每一项都描述了物理页面的状态。全局变量MnPfnDatabase是一个指向该数组的指针，以下是该全局变量的输出，可看到该数组的地址是0x80C00000

数组中的每一个元素都是一个MMPFN结构体，该结构体定义如下：

在WRK中的定义如下：

其中MMPFNENTRY结构定义如下：

数组中的每个元素都占0x1C字节的大小，因此要查看数组中的元素需要根据索引来乘以0x1C作为偏移，而索引值左移12位的地址就是数组中该元素所描述的物理页，比如以下查询的是索引为2的物理页面的状态，因此所查的物理页是0x200~0x2FFF页面的状态

当Intel x86处理器在执行一个执行流过程中，需要使用到地址页表项（PTE）来翻译一个虚拟地址引用，PTE结构如下图所示，其中的第0位（V位）代表了有效位，指定了该PTE是否是有效的

当有效位为0的时候，处理器会引发一个异常，也成为页面错误。Windows内核的陷阱处理器会把这一异常交给内存管理器的页面错误例程，由它来解决页面无效的问题。一般来说，只要这个页面错误是合理的，则页面错误处理例程将试图分配一个物理页面，并设置好PTE来消除虚拟地址引用错误，使得该地址引用能被正确地翻译成恰当地物理页面。由于异常是硬件触发地，而页面错误处理例程是操作系统提供的组件，所以这一页面分配并重映射的过程对于原始的指令流是完全透明的，最多只是时间上稍有停顿

如果一个PTE已经正确指向一个物理页面，则页面错误不会发生，虚拟地址翻译可快速进行。但是，随着进程使用越来越多的页面，最终系统的可用物理内存可能会消耗光。为了避免因内存消耗光而导致应用程序或系统的正常功能无法执行，现代操作系统提供了页面交换的能力，即把有些正在使用的页面中的内容存放到磁盘上，从而腾出这些物理页面以供使用。以后，当这些被换出到磁盘上的页面再次被引用时，页面错误处理例程在把它们换回内存中

Windows系统支持一个或多个页面文件（每个磁盘分区最多一个页面文件），用来存放被交换页面的内容。页面文件可被看做是物理内存的一种延伸。对于页面文件中的内容而言，页面文件域物理内存是同等的，只不过受页面调度的影响而在不同时刻位于不同的物理位置

当第0位（V位）为0的时候，此时的PTE就是一个无效PTE。此时，处理器引发页面错误异常，该异常的陷阱处理器把控制权交给页面处理例程，所以，PET其他位的含义由操作系统来解释。正是由于这一层灵活性，Windows才可以在这一的PTE中承载一些信息，以便实现页面管理功能。无效PTE有下图所示的4种情形：

情形一：如图中(a)所示，此时第10和11位为0，第1~4位指示了在哪个页面文件种，第12~31位共20位表示了该页面在页面文件中的偏移量，以页面单位（0x1000字节）为单位

情形二：如图中(b)所示，是第一种情形的特例，若1~4位和12~31位全为0，则表明这是一个待分配的页面，它需要一个填满零的页面

情形三：如图中(c)所示，第10位为1，说明这个页面尚在内存中，但正在换出过程中，位于系统的某个物理页面链表中。此时第12~31位指示了物理页帧编号，根据PFN数据库可用定位到该页面的实际状态

情形四：如图中(d)所示，是一个全零的PTE，此时该页面的状态无法确定，甚至该PTE对应的虚拟地址是否已被提交也不能确定，所以页面错误处理例程应检查VAD树中对应的节点，以确定页面的状态

当通过CreateFileMapping来创建内存区对象的时候，该函数的第三个参数flProtect指定了内存区对象的页面保护属性，可以是PAGE_READ, PAGE_READWRITE， PAGE_EXECUTE以及会产生写时复制的PAGE_WRITECOPY，该属性的含义是，如果一个进程要写这个页面，则生成器字节的私有拷贝，并且私有拷贝的保护属性为PAGE_READWRITE。而属性PAGE_READWRITE的含义是不管将来哪个进程读或者写这个页面，都始终只有一个页面，也就是说，完全共享这个页面

当一个进程使用内存区对象时，它必须映射一个视图，视图本身并不影响内存区对象的保护属性。然而，在视图所对应的VAD节点中包含了这一保护属性，代表该进程对于此内存区对象的操作类型。MMVAD结构中的u.VadFlags.Protection成员即为此目的。映像文件的视图，此值为MM_EXECUTE_WROTECPY，支持写时复制。而其他类型的视图，此值就会由函数MapVieOfFile来决定

通常将一个DLL文件装载进内存时所创建的内存区对象的属性就是写时复制，且相应的PTE的有效位也会是0，如下图是记事本进程的DLL内存区对象的属性

当程序对有写时复制属性的内存区进行写操作的时候，发现PTE是0，也就是无效PTE的时候，页面错误处理例程会检查其内存区对象属性。如果是写时复制属性，就会会这块内存在分配一块新的物理地址，这样对其写入的操作就会在这块物理地址中完成。这样做的好处就是，原来物理地址中的内容不会发生改变，就不会影响其他进程对该共享内存的使用

《Windows内核原理与实现》

《Windows内核设计思想》

[注意]传递专业知识、拓宽行业人脉——看雪讲师团队等你加入！