-
-
[翻译]《深入解析windows操作系统第6版下册》第10章:内存管理（第一部分）
-
发表于: 2015-9-16 23:38
-
在上册中文版的最后提到,下册中文版将于年内(当时是2014年)推出.可惜过了一年多,迟迟不见问市,
电子工业出版社网站也没有相关信息（只能搜索到上册中文版）；
于是突发奇想自行翻译英文原版下册.我在网上找到了英文原版下册的PDF版,最近在尝试翻译第10章: 内存管理,由于之前学习了一些相关的知识,因此翻译起来还不算太吃力。有兴趣的朋友可以一起来翻译下册（借助搜索引擎可以找到下载资源，51cto以及csdn社区都有），提出你想要翻译的章节，然后在这个子板块发表。
众所周知，该系列书籍是探索 windows 内部机理的首选材料，我们可以在翻译的过程中学到很多知识，同时提高自身的水平，遇到翻译困难的部分也可以互相交流学习；
本帖为原创翻译，采用中英对照，译注是自行添加的说明，内容会持续更新，由于工作的关系，翻译速度大约是一天1~2页原文，本帖仅翻译下册第10章（内容较多，可能会发表后续部分），上册的所有章节已经有中文版实体书和PDF版，可以搜索相关信息；个人所学有限，译文的错误之处还请提出指正，不胜感激。第一部分译文预计翻译的内容如下：
此外，考虑到帖子中，能够作为附件插入的图片有其数量上限，所有图片都外链到我的51cto博客（http://shayi1983.blog.51cto.com/）的相应博文中，它们实际上是在那里被上传的，因此特定图片带有水印，并且原始博文的更新进度会比这里的慢一些，希望各位别介意。
下面是原文＋译文
In this chapter, you’ll learn how Windows implements virtual memory and how it manages the subset of virtual memory kept in physical memory. We’ll also describe the internal structure and components that make up the memory manager, including key data structures and algorithms. Before examining these mechanisms, we’ll review the basic services provided by the memory manager and key concepts such as reserved memory versus committed memory and shared memory.
在本章中，你将学习windows如何实现虚拟内存，以及如何管理驻留在物理内存中的虚拟内存子集。我们也会描述组成“windows内存管理器”的内部结构和组件，包括关键数据结构和算法。
在考察这些机制之前，我们先回顾一下内存管理器提供的基础服务，以及诸如 reserved memory ， committed memory ，shared memory 这些重要概念。
By default, the virtual size of a process on 32-bit Windows is 2 GB. If the image is marked specifically as large address space aware, and the system is booted with a special option (described later in this chapter), a 32-bit process can grow to be 3 GB on 32-bit Windows and to 4 GB on 64-bit Windows.
The process virtual address space size on 64-bit Windows is 7,152 GB on IA64 systems and 8,192 GB on x64 systems. (This value could be increased in future releases.)
默认情况下，32位 windows上的一个进程的虚拟大小（地址空间）为2GB，如果该进程对应的二进制映像文件被特别标注了“large address space aware”（察觉到大地址空间），并且系统以特殊选项引导（本章稍后讨论），那么 32 位进程在 32 位 windows上的虚拟大小可达到 3GB；在64 位 windows 上的虚拟大小可达到 4GB；运行在 Intel IA-64 体系结构的 64 位 windows 上的 64 位进程的虚拟地址空间大小为 7152GB；在 x64 体系结构上则为 8192 GB；（在处理器硬件和操作系统软件的后续发布版中，这些值可能会增大）
（译注：用 visual studio 打开任意解决方案或工程文件，打开要进行编译的 .cpp 或其它格式的源文件，从主菜单中选择 “Project” -> “xxx Prooerties”，xxx是你的软件项目名称，将打开如下图所示的属性配置界面，从右侧的树型结构中选择“Linker” ->“System”，然后就可以配置链接器在生成该二进制文件时，标记启用大地址空间）
might be larger or smaller than the physical memory on the machine, the memory manager has two primary tasks:
■ Translating, or mapping, a process’s virtual address space into physical memory so that when a thread running in the context of that process reads or writes to the virtual address space, the correct physical address is referenced. (The subset of a process’s virtual address space that is
physically resident is called the working set. Working sets are described in more detail later in this chapter.)
■ Paging some of the contents of memory to disk when it becomes overcommitted—that is, when running threads or system code try to use more physical memory than is currently available— and bringing the contents back into physical memory when needed.
（译注：在第三部分译文中会讲到：在写作原文的时间点上，Intel 与 AMD 的 x64 体系结构仅使用了 64 位地址总线中的 48 位，因此 x64 处理器当前仅支持最多 256 TB 的虚拟内存—— 2 的 48 幂；而 64 位的 Windows 在此基础上，进一步限制了只能使用 16 TB 虚拟内存——用户空间与内核空间各占 8 TB，如前文所述。在这种情况下，64 位 Windows 支持的虚拟内存上限，即
16 TB——就比它支持的物理内存上限—— 2 TB—— 还要大；另外一种情况，即虚拟内存上限小于物理内存上限，大家应该都非常熟悉了——在你的 32 位 Windows 上，没有启用 PAE 和前述的“large address space aware”，那么无论你购置了多少 RAM 条，进程的虚拟内存上限顶多就 2 GB）
因此内存管理器的二个主要任务为：
■ 将一个进程的虚拟地址空间翻译或映射成物理内存，从而使运行在该进程上下文中的线程读写虚拟地址空间时，能够引用正确的物理地址。
（ windows 将驻留在物理内存中的进程虚拟地址空间子集称为“工作集”，它的更多细节将在本章后面描述）
■ 当物理内存过载时（例如，当运行的线程或内核代码尝试请求比当前可用内存更多的时候），将其中部分内容换出至磁盘，以及在需要时将这些内容换回（入）物理内存。
There is a Control Panel applet that provides control over the size, number, and locations of the paging files, and its nomenclature suggests that “virtual memory” is the same thing as the paging file. This is not the case. The paging file is only one aspect of virtual memory. In fact, even if you run with no page file at all, Windows will still be using virtual memory. This distinction is explained in more detail later in this chapter.
在控制面板中有一项提供对页面文件的大小，数量，以及位置的控制（译注：即“系统”选项卡-> 高级系统设置 ->高级选项卡 -> 单击性能栏目的“设置”，再切换到“高级选项卡”，单击“虚拟内存”栏目的“更改”）；其命名法指出“virtual memory”（虚拟内存）与分页文件是相同的概念；情况并非如此。分页文件仅仅是虚拟内存的一个方面（或子集）。实际上，即便你设置成完全不使用页面文件，windows 将依旧使用虚拟内存。本章后面将详细解释这之间的区别。
The memory manager is part of the Windows executive and therefore exists in the file Ntoskrnl.exe.
No parts of the memory manager exist in the HAL. The memory manager consists of the following components:
■ A set of executive system services for allocating, deallocating, and managing virtual memory,most of which are exposed through the Windows API or kernel-mode device driver interfaces
■ A translation-not-valid and access fault trap handler for resolving hardware-detected memory management exceptions and making virtual pages resident on behalf of a process
内存管理器是 windows 执行体的一部分，因此它存在于文件 Ntoskrnl.exe 之中。内存管理器没有任何部分是位于 HAL（译注：硬件抽象层）中的。内存管理器由下列组件构成：
■ 一组用于分配，释放，以及管理虚拟内存的执行体系统服务，其中多数通过Windows API或者内核模式设备驱动接口对外暴露；
■ 一个翻译无效和访问错误陷阱处理程序，用于解决硬件探测到的内存管理异常，以及代表一个进程，让它的部分虚拟页面驻留在物理内存中；（这句翻译的不好，原文是A translation-not-valid and access fault trap handler for resolving hardware-detected memory management exceptions and making virtual pages resident on behalf of a process。谁知道怎么翻译较好？）
另外一种更直观的方法是，用内核调试器的 !process 0 0 扩展命令列出当前系统上运行的所有进程，在其中找到 System 进程的 EPROCESS 结构的虚拟地址，然后用这个地址作为前述扩展命令的第一个参数；用 0xf 作为其第二个参数再次执行该命令，按照这种方式，能够列出进程浏览器不可见的所有 6 个下文描述的系统线程，包括进程浏览器无法查询的调用栈信息，下图展示了这种方法。）
如何理解上图中的线程启动地址“ntkrnlpa.exe!ObfDereferenceObjectWithTag+0xa9”？如果我们反汇编 ObfDereferenceObjectWithTag() 例程，可以发现地址 84295d7f 被标记为 nt!ObfDereferenceObjectWithTag+0xa7 ，该地址处的指令为 0x90，即 nop，或称空指令；
而紧接其后的地址——84295d80——也就是 KeBalanceSetManager() 例程的第一条机器指令的地址，按照这种偏移法来表达，就是“ntkrnlpa.exe!ObfDereferenceObjectWithTag+0xa8”，由此可见，进程浏览器的线程启动地址信息基本正确，只有一字节的误差，并且也验证了“ntkrnlpa.exe!ObfDereferenceObjectWithTag+0xa9”这个启动地址确实位于 KeBalanceSetManager() 例程起始处，因此这个系统线程就是平衡集管理器线程，参考下图。
working set manager
（MmWorkingSetManager，工作集管理器），后者每秒被调用一次；
（注意例程名称前缀的暗示：平衡集管理器以 Ke 开头，表明它是在更底层的内核中实现的；工作集管理器以 Mm 开头，表明它是在执行体组件——内存管理器——中实现的）。
此外，当可用内存低于某个阈值时，它也会被调用。工作集管理器会驱动整体的内存管理策略，例如工作集大小微调（裁剪），增加页面的使用年龄（译注：用于页面置换算法确定最近最少使用的页面，作为牺牲页换出内存），并且，如果牺牲页已被修改过，先将原修改数据写回磁盘上的交换空间（分页文件），然后再将该页面用于存储新数据。这个过程由 MiModifiedPageWriter() 例程负责，参见下文
swapper 的系统进程，通常在系统的空闲物理页框即物理内存不足，或者某些进程长时间没有获得调度从而变成非活动进程时，swapper 进程和 windows 的
process/stack swapper 线程被唤醒，将这些进程换出内存，从而释放空间。KeSwapProcessOrStack() 例程的操作会影响到线程的调度状态改变，例如，假设一个线程准备好执行，但它的内核栈[内核模式线程的情况]或调用栈/所属进程[用户模式线程的情况]，被换出了内存，则该线程进入转换状态。一旦这些栈或所属进程被换回至内存中，该线程进入就绪状态。关于对线程调度状态的讨论，请参考本书上册第五章的 5.7 节——线程调度）
（译注：WRK1.2 版源码中的 mminit.c 模块包含内存管理器系统的初始化逻辑，其中第 171~178 行定义了这个 5 分钟时限，节录如下：）
[COLOR="Black"][B]// Default is a 300 second life span for modified mapped pages - // This can be overridden in the registry. // [FONT="微软雅黑"]ULONG MmModifiedPageLifeInSeconds = 300;[/FONT][/B][/COLOR]
源码及其注释证实了，位于已修改页列表中的脏页的生存期就是 300 秒，如果超时将被写回磁盘
，注释还提到，该值可以通过编辑注册表的对应项来覆盖，但是没有给出具体的键路径。因为
MmModifiedPageLifeInSeconds 是一个全局变量，它可以被映射页面写入器访问，并据此作为页面回写磁盘的超时标准。
（这第二个）已修改页面写入器线程是必须的；如果只有一个已修改页面写回器线程，并且当前没有空闲页面，该线程可能因请求空闲页面而生成页面错误，此时该线程将被阻塞在等待产生空闲页面事件，但是又没有第二个能够将已修改页面写入磁盘，从而释放出空闲页面的线程可供调度，于是整个系统会进入死锁状态来等待空闲页面。（译注：这段译文经过自行润色，原文直译不好理解，希望没有偏离作者要表达的意思）
其中可以学习到如何正确地初始化事件，等待事件变成有信号，然后继续执行；同时还可以检验原文讲到的相关内容，对内核工作机制有更直观的理解。
首先，在 MiModifiedPageWriter() 这个系统线程中（modwrite.c 的 2943 行），调用 KeInitializeEvent() 初始化全局的 MmMappedPageWriterEvent 事件，注意，此次使用一个通知事件（因此我们将在后面看到，需要在 KeSetEvent() 后调用 KeClearEvent() 清除事件的有信号状态），且初始化状态为无信号。然后它创建 MiMappedPageWriter() 系统线程，这就是原文提到的“第二个已修改页面写入器线程”——用于写入映射文件页面（第一个则是
MiModifiedPageWriter() 自身）。并且初始化一个由 LIST_ENTRY 组成的全局双向链表头部，如下所示：
由 LIST_ENTRY 组成的双向链表示意图如下，在实践中通常会把 LIST_ENTRY 内嵌在一个更大的母结构体内部，每个这样的母结构体称为链表中的“表项”；一个表项可以通过自身的 LIST_ENTRY 成员引用前一个和后一个表项：
而在 MiMappedPageWriter() 中（modwrite.c 的 4397 行），它会调用并阻塞在 KeWaitForSingleObject() 内部，等待其它函数处理这个链表，如下所示：
MiModifiedPageWriter() 在创建 MiMappedPageWriter() 线程后，它会调用
MiModifiedPageWriterWorker()，后者进一步调用 MiGatherMappedPages()——它在返回前调用 InsertTailList()，在全局的双向链表尾部插入表项，然后调用 KeSetEvent() 把 MmMappedPageWriterEvent 事件设置为有信号，从而“唤醒”MiMappedPageWriter() 线程（从 KeWaitForSingleObject() 中返回），如下所示：
MiGatherMappedPages() 返回到它的调用者后，MiModifiedPageWriterWorker() 显式调用 KeClearEvent() 来清除事件。回忆一下，前面说到通知事件需要在设置后手动清除，如下所示：
另一方面，前几张的截图显示出，MiMappedPageWriter() 线程被唤醒后，会调用 IsListEmpty() 例程来判断 MiGatherMappedPages() 处理过的全局双向链表是否为空，然后再进行相应的处理。
再次强调：本系列书籍作者由于其职位敏感性，不能总是把源码摆出台面上来分析系统机制，
只能用一些技术性较强的句子来描述，这又造成了我们翻译的困难，因此当你对原文或译文中某些内容感觉云里雾里时，像我这样搜索 WRK 源码中的相关实现逻辑，甚至结合内核调试器来动态分析，对理解幕后原理和设计思想都会很有帮助，还能够学习这些内核例程，数据结构的用法，提升你的驱动编程水平。）
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]HANDLE ThreadHandle;
if (!NT_SUCCESS(PsCreateSystemThread (&ThreadHandle,
THREAD_ALL_ACCESS,
&ObjectAttributes,
0, [B] //第 4 个参数（HANDLE ProcessHandle）指明要在哪个进程中创建系统线程，如果此参数为 NULL，就在 System 进程中创建系统线程。[/B]
NULL,
MiDereferenceSegmentThread,
NULL))) {
return FALSE;
}
ZwClose (ThreadHandle);[/COLOR][/SIZE][/FONT]Unlike the other routines described here, this routine is not a top-level thread function but is called by the top-level thread routine
Phase1Initialization. MmZeroPageThread never returns to its caller, so in effect the Phase 1 Initialization thread becomes the zero page thread by calling this routine. Memory zeroing in some cases is done by a faster function called MiZeroInParallel. See the note in the section “Page List Dynamics” later in this chapter.
Each of these components is covered in more detail later in the chapter.
零页线程将空闲页列表（译注：可能通过类似单向链表的数据结构实现）中的页全部用 0 填充，然后换出内存，从而使得分页文件缓存中有全 0 的页面可用于满足将来的“零页需求”类型的页面错误，并且能够被换入内存。与这里描述的其它 5 类例程不同，此例程并非顶级线程函数，但是它会被一个叫做 Phase1Initialization 的顶级线程例程调用；
（译注： 系统引导分成第一阶段内核，执行体初始化，以及第二阶段的执行体初始化。在第一阶段的执行体初始化中的函数调用流程如下：
ExpInitializeExecutive() -> PsInitSystem() -> PspInitPhase0()
PspInitPhase0() 首先调用 PsGetCurrentProcess()，将自身转变为 Idle 进程，然后创建 system 进程，并在其中创建系统线程 Phase1Initialization，最后执行上下文切换将控制转交给 Phase1Initialization 线程，由后者负责第二阶段的执行体初始化；
而 Phase1Initialization 线程在最后则通过调用 MmZeroPageThread() ，将自身转变为零页线程。下面这张引用了《Windows 内核设计思想》一书中的图片，比较全面地概括了系统启动的流程：）
零页线程从不返回（到它的调用者），因此实际上，Phase1 初始化线程函数（在最后）通过调用此例程变成零页线程。内存清零操作有时候通过一个叫“MiZeroInParallel”的函数完成，其速度更快。更多细节请查看本章后面的“Page List Dynamics”（动态页列表？直译。。。）；
本章后面会涵盖上述 6 个内存管理器组件的更多细节。
（译注：为了避免只见树木不见林的弊端，下图给出内存管理器在整个Windows系统架构中的位置。注意，为求简洁，这张系统架构图省略了许多用户模式子系统DLL，内核模式组件，TCP/IP协议栈如tcpip.sys等。重点突出函数调用的轨迹，以及模块之间的依赖性。完整的系统架构图，各位可以参考本书上册第2章“关键的系统组件”一节）
Like all other components of the Windows executive, the memory manager is fully reentrant and supports simultaneous execution on multiprocessor systems—that is, it allows two threads to acquire resources in such a way that they don't corrupt each other's data. To accomplish the goal of being fully reentrant, the memory manager uses several different internal synchronization mechanisms, such as spinlocks, to control access to its own internal data structures. (Synchronization objects are discussed in Chapter 3, “System Mechanisms,” in Part 1.)
Some of the systemwide resources to which the memory manager must synchronize access include:
■ Dynamically allocated portions of the system virtual address space
■ System working sets
■ Kernel memory pools
■ The list of loaded drivers
■ The list of paging files
■ Physical memory lists
■ Image base randomization (ASLR) structures
■ Each individual entry in the page frame number (PFN) database
Per-process memory management data structures that require synchronization include the working set lock (held while changes are being made to the working set list) and the address space lock (held whenever the address space is being changed). Both these locks are implemented using pushlocks.
正如windows执行体的所有其它组件一样，内存管理器是完全可重入的，并且支持在多处理器系统上同时执行——换句话说，以这样的方式能够允许2个线程在不损坏彼此数据的情况下获取资源。为了实现可完全重入这一目标，内存管理器使用了几种不同的内部同步机制，例如自旋锁，用于控制对系统自身内部数据结构的访问（同步对象在本书上册第3章“系统机制”中讨论）
内存管理器必须对其访问进行同步化的一些系统范围资源包括：
■ 系统虚拟地址空间的动态分配部分；
■ 系统工作集；
■ 内核内存池；
■ 已加载驱动程序的列表；
■ 分页文件列表；
■ 物理内存列表；
■ 地址空间布局随机化（ASLR）使用的相关结构；
■ 页框号（PFN）数据库中，每个单独的条目；（译注：这里的页框号数据库，类似操作系统维护的页表；页框号即物理页号；页表中的每个条目称为页表项，即PTE。因此 PFN 中单一条目的作用就类似于 PTE）
内存管理事务涉及的每进程数据结构中，需要同步的包括：工作集锁（当工作集列表正在变更时持有该锁），地址空间锁（每当地址空间正被改变时持有该锁）。这些锁都使用推锁（pushlocks）实现。
The Memory and Process performance counter objects provide access to most of the details about system and process memory utilization. Throughout the chapter, we'll include references to specific performance counters that contain information related to the component being described. We've included relevant examples and experiments throughout the chapter.
One word of caution, however:
different utilities use varying and sometimes inconsistent or confusing names when displaying memory information. The following experiment illustrates this point. (We'll explain the terms used in this example in subsequent sections.)
“内存与进程性能计数器对象”提供对绝大多数与系统和进程内存使用率细节相关的访问。贯穿本章，我们将引用特定性能计数器，这些计数器包含与本章描述的内存管理器组件有关的信息，我们也涵盖了相应的例子与实验。然而，需要提醒一下：当显示内存信息时，不同的工具使用不同的——有时是不一致或让人困惑的名称。下面的实验说明了这一点。（我们将在后续部分解释这个例子中使用的术语）
The Performance tab in the Windows Task Manager, shown in the following screen shot, displays basic system memory information. This information is a subset of the detailed memory information available through the performance counters. It includes data on both physical and virtual memory usage.
如下的屏幕截图所示，windows任务管理器中的性能标签，显示基本的系统内存信息，这个信息仅是性能计数器提供的详细内存信息的一组子集，它包含物理内存和虚拟内存使用率相关的数据。
（原文使用EN-US语系的系统截图，我把它替换成自己机器上的ZH-CN语系截图，主要是方便大家对照下面的表格来理解图中每个术语的含义）
described later in the table. The total height of the graph is equal to the Total counter in that section. This represents the total RAM usable by the operating system, and does
not include BIOS shadow pages, device memory, and so on.
Cache Bytes, Modified Page List Bytes, Standby Cache Core Bytes,
Standby Cache Normal Priority Bytes, and Standby Cache Reserve Bytes (all in Memory object)
Two other Sysinternals tools show extended memory information:
■ VMMap shows the usage of virtual memory within a process to an extremely fine level of detail.
■ RAMMap shows detailed physical memory usage.
These tools will be featured in experiments found later in this chapter.
Finally, the !vm command in the kernel debugger shows the basic memory management information available through the memory-related performance counters. This command can be useful if you're looking at a crash dump or hung system. Here's an example of its output from a 4-GB Windows client system:
另外2个Sysinternals工具能够显示扩展的内存信息：
■ VMMap将一个进程内的虚拟内存使用情况显示到一个极端细致的水平；
■ RAMMap显示物理内存使用情况的细节；
本章后续将通过实验来展示这些工具的特色。
最后，内核调试器中的 !vm 命令通过内存相关的性能计数器显示可用的基本内存管理信息。如果你正检查一个崩溃转储或挂掉的系统，该命令可能有用。下面的例子来自于一个4GB物理内存的windows客户机系统上的输出：
[FONT="微软雅黑"][SIZE="4"]1: kd> !vm *** Virtual Memory Usage *** Physical Memory: 851757 ( 3407028 Kb) Page File: \??\C:\pagefile.sys Current: 3407028 Kb Free Space: 3407024 Kb Minimum: 3407028 Kb Maximum: 4193280 Kb Available Pages: 699186 ( 2796744 Kb) ResAvail Pages: 757454 ( 3029816 Kb) Locked IO Pages: 0 ( 0 Kb) Free System PTEs: 370673 ( 1482692 Kb) Modified Pages: 9799 ( 39196 Kb) Modified PF Pages: 9798 ( 39192 Kb) NonPagedPool Usage: 0 ( 0 Kb) NonPagedPoolNx Usage: 8735 ( 34940 Kb) NonPagedPool Max: 522368 ( 2089472 Kb) PagedPool 0 Usage: 17573 ( 70292 Kb) PagedPool 1 Usage: 2417 ( 9668 Kb) PagedPool 2 Usage: 0 ( 0 Kb) PagedPool 3 Usage: 0 ( 0 Kb) PagedPool 4 Usage: 28 ( 112 Kb) PagedPool Usage: 20018 ( 80072 Kb) PagedPool Maximum: 523264 ( 2093056 Kb) Session Commit: 6218 ( 24872 Kb) Shared Commit: 18591 ( 74364 Kb) Special Pool: 0 ( 0 Kb) Shared Process: 2151 ( 8604 Kb) PagedPool Commit: 20031 ( 80124 Kb) Driver Commit: 4531 ( 18124 Kb) Committed pages: 179178 ( 716712 Kb) Commit limit: 1702548 ( 6810192 Kb) Total Private: 66073 ( 264292 Kb) 0a30 CCC.exe 11078 ( 44312 Kb) 0548 dwm.exe 6548 ( 26192 Kb) 091c MOM.exe 6103 ( 24412 Kb)[/SIZE][/FONT]
Like other Windows executive services, the memory management services allow their caller to supply a process handle indicating the particular process whose virtual memory is to be manipulated.
The caller can thus manipulate either its own memory or (with the proper permissions) the memory of another process. For example, if a process creates a child process, by default it has the right to manipulate the child process’s virtual memory. Thereafter, the parent process can allocate, deallocate, read, and write memory on behalf of the child process by calling virtual memory services and passing a handle to the child process as an argument. This feature is used by subsystems to manage the memory of their client processes. It is also essential for implementing debuggers because debuggers must be able to read and write to the memory of the process being debugged.
内存管理器提供一组系统服务用于分配和释放虚拟内存，在进程间共享内存，将磁盘文件映射至内存，将虚拟页刷新到磁盘，检索一系列有关虚拟页的信息，更改虚拟页的保护属性，以及将虚拟页锁在内存中。与其它Windows执行体服务一样，内存管理服务允许它们的调用者提供一个进程句柄，用于指明要被操控虚拟内存的特定进程；调用者因而能够操控其自身内存，或者以适当的权限操纵其它进程的内存；例如，一个进程创建了一个子进程，默认情况下，父进程有权操控它的子进程的虚拟内存；随后，父进程可以通过调用虚拟内存服务并且传递一个该子进程的句柄作为参数，从而能够代表该子进程分配，释放，以及读写内存。这个特性被子系统用来管理它们“客户进程”的内存。这个特性对于实现调试器也是必需的，因为调试器必须能够读写被调试进程的内存。
smaller than a page; virtual memory functions, which operate with page granularity (Virtualxxx); and memory mapped file functions (CreateFileMapping, CreateFileMappingNuma, MapViewOfFile, MapViewOfFileEx, and MapViewOfFileExNuma). (We’ll describe the heap manager later in this
chapter.)
support routines that begin with Ex are used to allocate and deallocate from the system heaps (paged and nonpaged pool) as well as to manipulate look-aside lists. We’ll touch on these topics later in this chapter in the section “Kernel-Mode Heaps (System Memory Pools).”
堆函数（Heapxxx 以及旧版接口 Localxxx 与 Globalxxx，后2者在内部利用 Heapxxx APIs），它们可能被用来分配小于一页的内存；
虚拟内存函数（Virtualxxx），它们可用来操作页面的粒度（详情参考“大页面与小页面”一节）；
内存映射文件函数（CreateFileMapping，CreateFileMappingNuma，MapViewOfFile，MapViewOfFileEx，以及 MapViewOfFileExNuma）（本章稍后会介绍堆管理）
内存管理器也向执行体内的其它内核模式组件，以及设备驱动程序，提供了若干服务（例如分配和释放物理内存；锁住物理内存中的页面，用于直接存储器访问[DMA]的信号传输），这些函数名称以 Mm为前缀。此外，尽管不属于严格意义上的内存管理器一部分，一些以前缀 Ex 开头的执行体支持例程用于从系统堆（分页和非分页池）分配和释放内存，以及操控后备列表。
我们将在本章后面的“Kernel-Mode Heaps (System Memory Pools)”（内核模式堆[系统内存池]）部分中，讨论这些主题。
The virtual address space is divided into units called pages. That is because the hardware memory management unit translates virtual to physical addresses at the granularity of a page. Hence, a page is the smallest unit of protection at the hardware level. (The various page protection options are described in the section “Protecting Memory” later in the chapter.) The processors on which Windows runs support two page sizes, called small and large. The actual sizes vary based on the processor
architecture, and they are listed in Table 10-1.
虚拟地址空间被划分为叫做页面的单元。这是由于硬件内存管理单元（译注：即MMU）以页面为粒度将虚拟地址翻译成物理地址。于是，在硬件级别，一个页就是最小的保护单元。
（本章后续的“Protecting Memory”部分，将描述各种页面保护选项）。运行Windows的处理器支持２种页面尺寸，叫做小页和大页。页面的实际大小根据处理器体系结构而有所不同，表10-1列出了这些值：
TABLE 10-1 Page Sizes（页面大小）
同时，最近的x64处理器支持1GB的大页尺寸，但Windows没有使用该特性。
If small pages are used, more TLB entries are needed for the same range of virtual addresses, thus increasing recycling of entries as new virtual addresses require translation. This, in turn, means having to go back to the page table structures when references are made to virtual addresses outside the scope of a small page whose translation has been cached. The TLB is a very small cache, and thus large pages make better use of this limited resource.
如果我们使用小页面，需要更多的TLB条目来缓存相同范围的虚拟地址空间翻译结果（译注：例如，对于一个4MB地址空间范围，需要1024个4KB小页面；只需要1个4MB大页面就能覆盖），由于TLB条目数量是固定的，这导致可用于缓存其它范围虚拟地址空间翻译结果的条目越少。换言之，当引用的虚拟地址不在任何TLB条目缓存的小页面负责的范围内时，不仅需要回到页表结构中查找（译注：这就需要更多的CPU时钟周期，因为页表通常在内存中，内存访问比TLB访问至少慢上２个数量级），而且需要回收更多旧的TLB条目用于缓存新的翻译结果。TLB是一种非常小的缓存，在其中缓存大页面能够更高效使用这个有限的资源。
（译注：TLB一般可以存储64个PTE条目，如果使用每个PTE映射4KB地址空间的小页面，那么总共能缓存4*64 = 256KB的物理地址空间，如果使用4MB的大页面，则可以缓存4*64=256MB的物理地址空间，后者明显可以降低TLB未命中从而需要访问内存查询页表的几率，关于TLB缓存地址翻译结果的工作原理，可以参考下面这个视频解说：https://youtu.be/95QpHJX55bM）
device drivers to MmMapIoSpace) with large pages if the request is of satisfactory large page length and alignment. In addition, Windows allows applications to map their images, private memory, and page-file-backed sections with large pages. (See the MEM_LARGE_PAGE flag on the VirtualAlloc, VirtualAllocEx, and VirtualAllocExNuma functions.) You can also specify other device drivers to be mapped with large pages by adding a multistring registry value to HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\LargePageDrivers and specifying the names of the
drivers as separately null-terminated strings.
如果I/O地址空间请求（通过设备驱动程序调用MmMapIoSpace函数）能够符合大页面长度和对齐要求，Winodws也将自动使用大页面映射。此外，Windows还允许应用程序对它们的磁盘映像文件，私有内存（private memory），以及page-file-backed （暂译成“页面文件备份”）部分，使用大页面映射。（通过在VirtualAlloc，VirtualAllocEx，以及VirtualAllocExNuma函数参数中指定MEM_LARGE_PAGE标志）
你也可以通过向注册表路径HKLM\SYSTEM\CurrentControlSet\Control\SessionManager\Memory Management\
添加一个名为 “LargePageDrivers”的多字符串值，然后指定以空字符（译注：0x00）结尾并分隔的驱动程序名称字符串作为其数据，从而配置这些设备驱动程序使用大页面映射。（译注：参照原文，本句有更好的译法请提出，不胜感激）
begin on a large page boundary. (For example, physical pages 0 through 511 could be used as a large page on an x64 system, as could physical pages 512 through 1,023, but pages 10 through 521 could not.) Free physical memory does become fragmented as the system runs. This is not a problem for allocations using small pages but can cause large page allocations to fail.
在这种情况下，系统运行期间，空闲物理内存确实会变得碎片化。使用小页面来分配就不会有问题；使用大页面有可能造成分配失败。
mapped with a single protection that applies to the entire page (because hardware memory protection is on a per-page basis). If a large page contains, for example, both read-only code and read/write data, the page must be marked as read/write, which means that the code will be writable. This means that device drivers or other kernel-mode code could, as a result of a bug, modify what is supposed to be read-only operating system or driver code without causing a memory access violation.
If small pages are used to map the operating system’s kernel-mode code, the read-only portions of Ntoskrnl.exe and Hal.dll can be mapped as read-only pages. Using small pages does reduce efficiency of address translation, but if a device driver (or other kernel-mode code) attempts to modify a readonly part of the operating system, the system will crash immediately with the exception information pointing at the offending instruction in the driver. If the write was allowed to occur, the system would likely crash later (in a harder-to-diagnose way) when some other component tried to use the corrupted data.
Pages in a process virtual address space are free, reserved, committed, or shareable. Committed and shareable pages are pages that, when accessed, ultimately translate to valid pages in physical memory.
Committed pages are also referred to as private pages. This reflects the fact that committed pages cannot be shared with other processes, whereas shareable pages can be (but, of course, might be in use by only one process).
一个进程虚拟地址空间中的页面可能属于下列一种：free（空闲的）, reserved（保留的）, committed（提交的）, shareable（可共享的）。
其中，提交和共享的页面在被访问时，最终将转换（翻译）成物理内存中合法有效的页面。提交的页面也简称为private（私有的）页面。这反映出一个事实，即提交的页面不能被其它进程共享，而可共享的页面则可以（当然，只能同时被一个进程使用）。
“Private” refers to the fact that these pages are normally inaccessible to any other process.
如果有对物理内存的需求，私有提交页面随后将自动被操作系统写入分页文件（从而释放内存空间）。“私有的”指一事实：即这些页面对任何其它进程而言，通常是不可访问的。
ReadProcessMemory and WriteProcessMemory, that apparently permit cross-process memory access, but these are implemented by running kernel-mode code in the context of the target process (this is referred to as attaching to the process). They also require that either the security descriptor of the target process grant the accessor the PROCESS_VM_READ or PROCESS_VM_WRITE right, respectively, or that
the accessor holds SeDebugPrivilege, which is by default granted only to members of the Administrators group.
When a shared page is first accessed by any process, it will be read in from the associated mapped file (unless the section is associated with the paging file, in which case it is created as a zero-initialized page). Later, if it is still resident in physical memory, the second and subsequent processes accessing it can simply use the same page contents that are already in memory. Shared pages might also have been prefetched by the system.
当一个共享的页面首次被任何进程访问时，将从（磁盘上）关联的映射文件读入内存（直到该部分与页面文件关联，在此情况下，它被作为一个初始化为零的页面[zero-initialized page]创建）。
随后，如果此共享页面仍旧驻留在物理内存中，第二个以及后续的进程访问时，可以简单地使用已经在内存中的页面内容（与磁盘上的相同）。共享的页面也可能已经被系统预取（prefetched）进内存，甚至不需要等待进程首次访问才读入。
sets and the modified list are explained later in this chapter.) Mapped file pages can also be written back to their original files on disk as a result of an explicit call to FlushViewOfFile or by the mapped page writer as memory demands dictate.
it is neither committed nor reserved.
or constructed is the relatively small internal data structures that represent the state of the process address space. (We’ll explain these data structures, called page tables and virtual address descriptors, or VADs, later in the chapter.)
The TestLimit utility (which you can download from the Windows Internals book webpage) can be used to allocate large amounts of either reserved or private committed virtual memory, and the difference can be observed via Process Explorer. First, open two Command Prompt windows.
Invoke TestLimit in one of them to create a large amount of reserved memory:
TestLimit工具（您可以从本书的web页面下载）可以用于分配大量的保留，或者私有提交虚拟内存，这两者的差异可以通过进程浏览器（Process Explorer）来观察。首先，打开2个命令行提示符窗口。在其中一个调用TestLimit命令创建一段大量的保留内存：
[FONT="微软雅黑"][SIZE="4"]C:\temp>testlimit -r 1 -c 800 Testlimit v5.2 - test Windows limits Copyright (C) 2012 Mark Russinovich Sysinternals - wwww.sysinternals.com Process ID: 1544 Reserving private bytes 1 MB at a time ... Leaked 800 MB of reserved memory (800 MB total leaked). Lasterror: 0 The operation completed successfully.[/SIZE][/FONT]
[FONT="微软雅黑"][SIZE="4"]C:\temp>testlimit -m 1 -c 800 Testlimit v5.2 - test Windows limits Copyright (C) 2012 Mark Russinovich Sysinternals - wwww.sysinternals.com Process ID: 2828 Leaking private bytes 1 KB at a time ... Leaked 800 MB of private memory (800 MB total leaked). Lasterror: 0 The operation completed successfully.[/SIZE][/FONT]
Finally, invoke Process Explorer. Choose View, Select Columns, select the Process Memory tab, and enable the Private Bytes and Virtual Size counters. Find the two TestLimit processes in the main display:
（译注：前文提到，“保[预]留内存是相对廉价的操作，因为它只消耗非常少的内存”，也许就是它的Private Bytes只有2.8M，而不是822M的原因。而对于Virtual Size计数器，不论是保留的还是提交的，都会将其考虑在内，这一点是需要注意的。下面提供在我自己机器上的实验截图，结果基本与上面描述的类似：）
On Task Manager’s Performance tab, there are two numbers following the legend Commit. The memory manager keeps track of private committed memory usage on a global basis, termed commitment or commit charge; this is the first of the two numbers, which represents the total of all committed virtual memory in the system.
There is a systemwide limit, called the system commit limit or simply the commit limit, This limit corresponds to the current total size of all paging files, plus the amount of RAM that is usable by the operating system.
This is the second of the two numbers displayed as Commit on Task Manager’s Performance tab. The memory manager can increase the commit limit automatically by expanding one or more of the paging files, if they are not already at their configured maximum size.
Commit charge and the system commit limit will be explained in more detail in a later section.
在任务管理器的性能选项卡，“提交（GB）”后面跟着2个数值。内存管理器在全局基础上，跟踪记录私有提交内存的使用情况，这被称为commitment 或 commit charge，即第一个数值，它代表系统中所有提交的虚拟内存总合。还有一个系统级限制，叫做system commit limit 或者简称 commit limit，这个限制对应当前的所有分页文件总大小，增加可被操作系统使用的物理内存总量，即第二个数值。内存管理器可以通过扩展一个或多个分页文件，自动增加commit limit上限。（如果它们尚未配置最大上限）。本章后面部分将详细解释Commit charge 与 system commit limit。
（译注：经过实践发现，能为进程分配的虚拟内存大小受限于“system commit limit”的大小，即系统探测到的物理内存大小加上分页文件的大小，例如，在32位系统上，假设识别到的物理内存总量为3GB，并且设置了初始大小为2GB的分页文件，那么system commit limit的值为5GB；如果所有当前运行的进程被分配的虚拟内存总合达到这个限制，新的进程将无法运行，windows会给出页面文件太小，无法执行应用程序的错误提示；例如，运行vmware至少需要2GB的空闲system commit，以前面的5GB上限为例，如果当前的system commit已经使用了3GB，那么将无法运行vmware，即便勉强启动程序，系统的响应速度也会变得异常缓慢。此时可以通过增大页面文件的默认最小值来扩大“交换区”的大小，好让更多当前用不到的物理内存页能够交换到磁盘[因为磁盘的页面文件交换区已经扩大]，从而给vmware的进驻内存准备更多的空间。配置的方法：在计算机上右击 ->属性 -> 高级系统设置 ->高级选项卡 -> 单击性能栏目的“设置”，再切换到“高级选项卡”，单击“虚拟内存”栏目的“更改”。虚拟内存的用词可能会产生误导，实际上它就是用来配置磁盘页面文件大小的。
使用sysinternal的进程浏览器，单击最上方工具栏右侧的第二个矩形区域，就能显示system commit的统计数据。另外还要注意一点：
由于32位windows的内核代码限制了系统识别的物理内存上限为4GB，再扣掉为硬件寻址[CPU芯片内的核心显卡共享系统内存，外围I/O设备自带的硬件缓冲区映射系统内存等等]保留的地址空间，实际能使用的仅有3GB左右的物理内存，下图给出为了寻址各种总线，总线控制器，以及充当集成显卡显存，而保留的内存范围例子：
因此无法通过添加物理内存的容量来提高system commit上限，只能通过增大页面交换文件的方式，而推荐设置的页面文件大小通常是识别出的物理内存的1.5~2倍；
这意味着32位windows 的页面文件大小为4.5~6GB，则system commit limit的值就为7.5~9GB；相反，64位windows内核代码支持CPU的48位地址总线模式，可以寻址16TB地址空间[Intel X64体系结构当前使用48位地址总线，理论上支持256TB地址空间，但是64位windows仅使用其中的44位，因此只能寻址16TB物理内存]，以及通过各种非官方渠道开启物理地址扩展[PAE补丁]的32位windows，可以使用36位地址空间，也就是能够识别64GB物理内存，所以在64位windows和32位 PAE windows上，可以通过添加物理内存的容量来提高system commit上限，从而能够“同时”运行更多应用程序；一般而言，增大物理内存会比增大页面交换文件来的有效。）
In general, it’s better to let the memory manager decide which pages remain in physical memory.
However, there might be special circumstances where it might be necessary for an application or device driver to lock pages in physical memory. Pages can be locked in memory in two ways:
■ Windows applications can call the VirtualLock function to lock pages in their process working set. Pages locked using this mechanism remain in memory until explicitly unlocked or until the process that locked them terminates. The number of pages a process can lock can’t exceed its minimum working set size minus eight pages. Therefore, if a process needs to lock more pages, it can increase its working set minimum with the SetProcessWorkingSetSizeEx function (referred to in the section “Working Set Management”).
■ Device drivers can call the kernel-mode functions MmProbeAndLockPages, MmLockPagableCodeSection, MmLockPagableDataSection, or
MmLockPagableSectionByHandle. Pages locked using this mechanism remain in memory until explicitly unlocked. The last three of these APIs enforce no quota on the number of pages that can be locked in memory because the resident available page charge is obtained when the driver first loads; this ensures that it can never
cause a system crash due to overlocking. For the first API, quota charges must be obtained or the API will return a failure status.
一般而言，最好让内存管理器决定哪些页面保留在物理内存中。然而，可能出现应用程序或设备驱动程序有必要在物理内存中锁定页面的特殊情况。有2种途径可以将页面锁在内存中：
■ Windows应用程序可以调用VirtualLock函数，在它们的进程工作集中锁定页面。页面锁定使用这种机制保留在物理内存中，直到显式解锁，或者直到锁定的进程终止。一个进程可以锁定的页面数量不能超出它的最小工作集大小减去8个页。因此，如果一个进程需要锁定更多页面，它可以通过SetProcessWorkingSetSizeEx函数，增加它的最小工作集（在“工作集管理”部分会提到）。
■ 对于设备驱动程序，可以调用内核模式函数MmProbeAndLockPages，MmLockPagableCodeSection，MmLockPagableDataSection，或者 MmLockPagableSectionByHandle。
页面锁定使用这种机制保留在物理内存中，直到显式解锁。最后3个APIs 强制无配额可被锁在内存中的页面数量，因为当驱动首次加载时，就获取了驻留在内存中的可用页面“装量”；强制无法配额可以确保驱动程序绝不会因为锁定过多的页面导致系统崩溃。对于第一个API（函数），必须获得配额装量，否则该函数会返回一个失败状态。（译注：本段译文不尽理想，有更好的译法请提出或指正）
Windows aligns each region of reserved process address space to begin on an integral boundary defined by the value of the system allocation granularity, which can be retrieved from the Windows GetSystemInfo or GetNativeSystemInfo function. This value is 64 KB, a granularity that is used by the memory manager to efficiently allocate metadata (for example, VADs, bitmaps, and so on) to support various process operations. In addition, if support were added for future processors with larger page
sizes (for example, up to 64 KB) or virtually indexed caches that require systemwide physical-to-virtual page alignment, the risk of requiring changes to applications that made assumptions about allocation alignment would be reduced.
Windows将每个保留的进程地址空间区域，按照一个完整的边界为起始进行对齐，这由系统分配粒度值定义，该值可以通过Windows函数GetSystemInfo 或 GetNativeSystemInfo 检索。
这个值的大小为64KB，是被内存管理器使用的一个粒度，用于高效分配元数据（例如VADs，位图等等）来支持各种进程操作。此外，如果往后的处理器增加了对大页尺寸的支持（例如，最多到64KB），或者增加虚拟索引缓存（要求全系统的物理页对齐虚拟页），将减少变成要求应用程序来假设分配对齐（粒度）的风险。
granularity.
region, the actual amount reserved would be 24 KB. Note that the VAD for the allocation would then also be rounded to 64-KB alignment/length, thus making the remainder of it inaccessible. (VADs will be described later in this chapter.)
As is true with most modern operating systems, Windows provides a mechanism to share memory among processes and the operating system. Shared memory can be defined as memory that is visible to more than one process or that is present in more than one process virtual address space. For example, if two processes use the same DLL, it would make sense to load the referenced code pages for that DLL into physical memory only once and share those pages between all processes that map the DLL, as illustrated in Figure 10-1.
与多数现代操作系统一样，Windows 提供一种机制用于在进程和操作系统之间共享内存。共享内存可以被定义为：多于一个进程可见的，或者存在于多个进程虚拟地址空间中的内存。举例来说，如果 2 个进程使用相同的 DLL，合理的做法是，只需要将该 DLL 中被引用的代码页加载进物理内存一次，并且在所有映射该 DLL 的进程间共享那些页面，如图 10-1 所示：
several other types like screen savers (.scr), which are essentially DLLs under other names) are mapped as execute-only and writable pages are mapped as copy-on-write. (See the section “Copy-on-Write” for more information.)
The underlying primitives in the memory manager used to implement shared memory are called section objects, which are exposed as file mapping objects in the Windows API. The internal structure and implementation of section objects are described in the section “Section Objects” later in this chapter.
This fundamental primitive in the memory manager is used to map virtual addresses, whether in main memory, in the page file, or in some other file that an application wants to access as if it were in memory. A section can be opened by one process or by many; in other words, section objects don’t necessarily equate to shared memory.
内存管理器中用来实现共享内存的底层原语叫做 section objects（暂译为"section 对象" ），它作为（或通过）Windows API 中的文件映射对象对外暴露。
本章后面的“Section Objects”小节将解释 section 对象的内部结构与实现。
内存管理器中的这个基本原语用于映射虚拟地址，无论是在主存中，分页文件中，或者在应用程序要访问的一些其它文件中，通过 section 对象，在进程看来就好像在内存中一样。一个 section 可以被一个或多个进程开启；换句话说，section 对象不一定等同于共享内存。
sections might in fact be “backed” only by physical memory.) As with any other empty page that is made visible to user mode (such as private committed pages), shared committed pages are always zero-filled when they are first accessed to ensure that no sensitive data is ever leaked.
can open it with OpenFileMapping. Or you can grant access to section objects through either handle inheritance (by specifying that the handle be inheritable when opening or creating the handle) or handle duplication (by using DuplicateHandle). Device drivers can also manipulate section objects with the ZwOpenSection, ZwMapViewOfSection, and ZwUnmapViewOfSection functions.
（译注：CreateFileMapping 函数原型如下：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]HANDLE CreateFileMapping( HANDLE hFile, LPSECURITY_ATTRIBUTES lpFileMappingAttributes, DWORD flProtect, DWORD dwMaximumSizeHigh, DWORD dwMaximumSizeLow, LPCTSTR lpName );[/COLOR][/SIZE][/FONT]
第一个参数就是要映射到的文件句柄，其值为 INVALID_HANDLE_VALUE，即无效的句柄值时，实际上是创建了实现共享内存的内核对象（section 对象），因为没有任何文件句柄与一个打开的磁盘文件关联；第二个参数是一个 SECURITY_ATTRIBUTES 结构类型的变量；该结构定义如下：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]typedef struct _SECURITY_ATTRIBUTES {
DWORD nLength;
LPVOID lpSecurityDescriptor; //只有该成员与安全性有关
BOOL bInheritHandle;
} SECURITY_ATTRIBUTES, *PSECURITY_ATTRIBUTES, *LPSECURITY_ATTRIBUTES;[/COLOR][/SIZE][/FONT]
其中第二个成员就是原文提及的“安全描述符”；如果我们想对创建的内核对象施加访问控制，就必须创建一个 lpSecutrtyDescripter，分配并初始化 SECURITY_ATTRIBUTES 结构：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]SECURITY_ATTRIBUTES sa; sa.nLength = sizeof(sa); sa.lpSecutrtyDescripter = pSD; sa.bInheritHandle = FALSE;[/COLOR][/SIZE][/FONT]
调用创建内核对象的函数时，将 SECURITY_ATTRIBUTES 结构变量的地址作为第二个实参传入：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]HANDLE hFileMapping = CreateFileMapping(INVALID_HANDLE_VALUE, &sa, PAGE_READWRITE, 0, 1024, TEXT("MyFileMapping"));[/COLOR][/SIZE][/FONT]最后一个参数就是原文提及的可选的 section 名称，使用 TEXT 宏的目的在于根据编译器的UNICODE 设置情况，自动转换名称为 ASCII/ANSI 或 unicode 字符串。原文提到，如果有section 名称，其它进程可以通过 OpenFileMapping 函数将其打开，也就是如下调用：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]HANDLE hFileMapping = OpenFileMapping(FILE_MAP_READ, FALSE, TEXT("MyFileMapping"));[/COLOR][/SIZE][/FONT]将 FILE_MAP_READ 作为第一个参数传给 OpenFileMapping，表明在获得对这个内核对象的访问权后，要从中读取数据。OpenFileMapping 函数在返回一个有效的句柄值前，会先执行一次安全检查。如果当前登录的用户或以特定用户帐户身份执行的进程被允许访问该文件映射内核对象（section 对象），OpenFileMapping 返回一个有效的句柄值；如果访问被拒绝，则返回 NULL；此时调用 GetLastError，返回值为 5（ERROR_ACCESS_DENIED）。同样的，如果利用返回的有效句柄调用其它 Windows API，但被调函数需要的权限不是 FILE_MAP_READ，也会发生拒绝访问错误。
下面的例子中，父进程在创建一个互斥量内核对象时，使用了句柄继承：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]SECURITY_ATTRIBUTES sa; sa.nLength = sizeof(sa); sa.lpSecutrtyDescripter = NULL; sa.bInheritHandle = TRUE; HANDLE hMutex = CreateMutex(&sa, FALSE, NULL);[/COLOR][/SIZE][/FONT]
根据 MSDN 上相关内容的解释，在调用需要 SECURITY_ATTRIBUTES 结构实例作为参数的函数时（多数创建内核对象的函数都要求此参数），如果将其设置为 NULL，或者将其 lpSecutrtyDescripter 成员设置为 NULL（如上述代码所示），那么创建的对象具有默认安全性——来自于调用或创建者的安全令牌（例如 ACLs ，访问控制列表）。
其次，如果将 SECURITY_ATTRIBUTES 结构的 bInheritHandle 成员设置为 TRUE，然后向 CreateMutex() 传入这个结构实例的地址，那么该函数返回的互斥量句柄值是可继承的。如此一来，在父进程的内核对象句柄表中将添加一项互斥量句柄值，其“可继承的标志位” = 1。
接着，父进程调用 CreateProcess() 创建子进程时，将前面的句柄值作为 CreateProcess() 的第2个参数 pszCommandLine 传递，并且将第5个参数 bInheritHandles 的值设为 TURE（表明“主动”请求继承；反之如果 bInheritHandles = FALSE ，则无论 SECURITY_ATTRIBUTES 结构的 bInheritHandle 成员值为何，都不会继承 ），这样子进程就会继承父进程句柄表中，可继承的标志位 = 1 的句柄。然后父子进程可以使用相同的句柄值访问同一个互斥量对象。CreateProcess() 函数原型如下：
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]BOOL WINAPI CreateProcess( _In_opt_ LPCTSTR lpApplicationName, _Inout_opt_ LPTSTR lpCommandLine, _In_opt_ LPSECURITY_ATTRIBUTES lpProcessAttributes, _In_opt_ LPSECURITY_ATTRIBUTES lpThreadAttributes, _In_ BOOL bInheritHandles, _In_ DWORD dwCreationFlags, _In_opt_ LPVOID lpEnvironment, _In_opt_ LPCTSTR lpCurrentDirectory, _In_ LPSTARTUPINFO lpStartupInfo, _Out_ LPPROCESS_INFORMATION lpProcessInformation ); [/COLOR][/SIZE][/FONT]
CreateProcess() 是一个复杂的函数，它拥有 10 个参数，每个参数都足够复杂，因此想要用好 CreateProcess() 并不容易。详细用法可以参考 MSDN 网站上的原文；日后有机会再发一帖该原文的原创翻译。
句柄继承导致增加内核对象的使用计数，因为父子进程引用相同的对象；仅当父子进程都调用 CloseHandle() 关闭引用该对象的句柄，或者父子进程都退出，让使用计数 = 0，该对象才会实际在内核空间中被销毁。强调一下，如果此后父进程又创建新的内核对象并将其设置为可继承的，现存子进程并不会自动继承新的对象，句柄继承仅发生在 CreateProcess() 调用并传入了相关参数时。
）
(If the paging file backs a section object, sufficient space must exist in the paging file and/or RAM to contain it.) To access a very large section object, a process can map only the portion of the section object that it requires (called a view of the section) by calling the MapViewOfFile, MapViewOfFileEx, or MapViewOfFileExNuma function and then specifying the range to map. Mapping views permits processes to conserve address space because only the views of the section object needed at the time must be mapped into memory.
the cache manager integrates with the memory manager, see Chapter 11, “Cache Manager.”) The implementation of shared memory sections, both in terms of address translation and the internal data structures, is explained later in this chapter.
本章后面会解释共享内存部分的实现，包括地址翻译和内部数据结构两方面。
You can list the memory mapped files in a process by using Process Explorer from Sysinternals.
To view the memory mapped files by using Process Explorer, configure the lower pane to show the DLL view. (Click on View, Lower Pane View, DLLs.) Note that this is more than just a list of DLLs—it represents all memory mapped files in the process address space. Some of these are DLLs, one is the image file (EXE) being run, and additional entries might represent memory mapped data files.
For example, the following display from Process Explorer shows a WinDbg process using
several different memory mappings to access the memory dump file being examined. Like most Windows programs, it (or one of the Windows DLLs it is using) is also using memory mapping to access a Windows data file called Locale.nls, which is part of the internationalization support in Windows. You can also search for memory mapped files by clicking Find, DLL. This can be useful when trying to determine which process(es) are using a DLL or a memory mapped file that you are trying to replace.
你可以通过使用来自 Sysinternals 的进程浏览器，列出一个进程中的内存映射文件。要这么做，将进程浏览器的下窗格配置成显示“DLL view”（点击主菜单中的”View“->“Lower Pane View”
->“DLLs”。）注意，DLL view 不仅仅是一份 DLLs 列表——它代表该进程地址空间中的所有内存映射文件。其中一些是 DLLs，有一个是正在运行进程的对应磁盘映像文件（EXE），其它项目可能代表着内存映射数据文件。举例来说，下面的进程浏览器截图显示出一个 WinDbg 进程使用几种不同的内存映射来访问被审查的内存转储文件。如同多数 Windows 程序，该进程（或者它正使用的其中一个 Windows DLL）亦使用内存映射来访问一个叫做 Locale.nls 的 Windows 数据文件；Locale.nls 是 Windows 中支持国际化的组成部分。你也可以通过点击主菜单“Find”->“DLL”，来搜索内存映射文件。在试图判断那个或哪些进程正使用一个 DLL，或者尝试替换一个内存映射文件时，这可能会有所帮助。
As explained in Chapter 1, “Concepts and Tools,” in Part 1, Windows provides memory protection so that no user process can inadvertently or deliberately corrupt the address space of another process or of the operating system. Windows provides this protection in four primary ways.
First, all systemwide data structures and memory pools used by kernel-mode system components can be accessed only while in kernel mode—user-mode threads can’t access these pages. If they attempt to do so, the hardware generates a fault, which in turn the memory manager reports to the thread as an access violation.
如同在本书上册第一章“概念和工具”中解释的，Windows 提供内存保护机制， 以至于没有用户进程可以无意或刻意损坏另一个进程或操作系统的地址空间。Windows 通过4种主要方式提供内存保护。
第一，所有内核模式系统组件使用的系统级别数据结构和内存池，只能够在内核模式下被访问——用户模式线程不能够访问这些页面。如果试图这么做，硬件生成一个错误，从而内存管理器反过来向该线程报告一个非法访问。
object (or holds SeDebugPrivilege) and thus can use the ReadProcessMemory or WriteProcessMemory function. Each time a thread references an address, the virtual memory hardware, in concert with the memory manager, intervenes and translates the virtual address into a physical one. By controlling how virtual addresses are translated, Windows can ensure that threads running in one process don’t
inappropriately access a page belonging to another process.
Third, in addition to the implicit protection virtual-to-physical address translation offers, all processors supported by Windows provide some form of hardware-controlled memory protection (such as read/write, read-only, and so on); the exact details of such protection vary according to the processor.
For example, code pages in the address space of a process are marked read-only and are thus protected from modification by user threads.
Table 10-2 lists the memory protection options defined in the Windows API. (See the VirtualProtect, VirtualProtectEx, VirtualQuery, and VirtualQueryEx functions.)
第三，除了提供虚拟到物理地址翻译的隐式保护之外，所有Windows支持的处理器提供某种形式的“硬件控制内存保护机制”（例如读/写，只读等等）；这种保护机制的具体细节因处理器而异。
例如，一个进程地址空间中被标记为只读的代码页因而能够防止被用户线程修改。
表10-2列出了Windows API 中定义的内存保护选项（参见 VirtualProtect，VirtualProtectEx，VirtualQuery，以及VirtualQueryEx函数的说明文档）
to contain a mapped file. To create the section, the thread must have at least read access to the underlying file object or the operation will fail.
Once a thread has successfully opened a handle to a section, its actions are still subject to the memory manager and the hardware-based page protections described earlier. A thread can change the page-level protection on virtual pages in a section if the change doesn’t violate the permissions in the ACL for that section object. For example, the memory manager allows a thread to change the pages of a read-only section to have copy-on-write access but not to have read/write access. The copy-on-write access is permitted because it has no effect on other processes sharing the data.
一旦线程成功的打开到一个节的句柄，其行为仍旧受到内存管理器与基于硬件的页面保护限制。一个线程可以更改节对象中虚拟页的页级保护属性，前提是这个更改没有违反该节对象ACL中的权限。举例来说，内存管理器允许一个线程将一个只读节中的页面改变为写时复制访问，但是不能改变为可读写访问。允许改变为写时复制访问是因为这不会影响其它进程共享只读的数据。（译注：即前文讲过的，在线程请求写入时，创建一个只有该线程可见的私有副本页，其对进行写操作不会改变原始的只读共享页）
No execute page protection (also referred to as data execution prevention, or DEP) causes an attempt to transfer control to an instruction in a page marked as “no execute” to generate an access fault.
This can prevent certain types of malware from exploiting bugs in the system through the execution of code placed in a data page such as the stack. DEP can also catch poorly written programs that don’t correctly set permissions on pages from which they intend to execute code. If an attempt is made in kernel mode to execute code in a page marked as no execute, the system will crash with the ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY bugcheck code. (See Chapter 14, “Crash Dump Analysis,” for an explanation of these codes.) If this occurs in user mode, a STATUS_ACCESS_VIOLATION (0xc0000005) exception is delivered to the thread attempting the illegal reference.
If a process allocates memory that needs to be executable, it must explicitly mark such pages by specifying the PAGE_EXECUTE, PAGE_EXECUTE_READ,
PAGE_EXECUTE_READWRITE, or PAGE_EXECUTE_WRITECOPY flags on the page granularity memory allocation functions.
不可执行页保护（也被称为数据执行保护，或DEP）导致试图转移（对CPU的）控制到一个标记为“不可执行”页中的指令时，生成一个访问错误。这可以防止某些类型的恶意软件通过将可执行代码放置在比如栈这种数据页中，从而利用系统中的缺陷或漏洞。DEP也能够捕捉到那些编写不当的程序，这些程序没有为它们打算从中执行代码的页面设置正确的权限。假设在内核模式下尝试在一个标记为不可执行的页中执行代码，系统会崩溃，并且错误检查码为ATTEMPTED_EXECUTE_OF_NOEXECUTE_MEMORY。（参见第14章，“崩溃转储分析”，其中有对这些代码的解释）
如果上述情况发生在用户模式，会传递一个STATUS_ACCESS_VIOLATION(0xc0000005)异常到尝试非法引用的线程。如果一个进程申请分配的内存需要能够被执行，进程必须通过在页面粒度内存分配函数中指定PAGE_EXECUTE，PAGE_EXECUTE_READ，PAGE_EXECUTE_READWRITE，或者PAGE_EXECUTE_WRITECOPY标志，来显式标记此类页面。
section “Physical Address Extension (PAE)” later in this chapter.) Thus, support for hardware DEP on 32-bit systems requires loading the PAE kernel (%SystemRoot%\System32\Ntkrnlpa.exe), even if that system does not require extended physical addressing (for example, physical addresses greater than 4 GB). The operating system loader automatically loads the PAE kernel on 32-bit systems that support hardware DEP. To force the non-PAE kernel to load on a system that supports hardware DEP, the BCD option nx must be set to AlwaysOff, and the pae option must be set to ForceDisable.
此外，还需要检查注册表项HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management，其右侧名称为 PhysicalAddressExtension 的 REG_DWORD 类型值是否为16进制的1，1表示启用PAE，0表示禁用PAE。最后，当IA32_EFER 寄存器的 NXE 标志置1，并且PDE/PTE 的比特位63（XD，第64位）置1时，就无法从被引用的页中取指令，这些页可能用于栈，数据段，以及堆。
pages not specifically marked as executable, kernel paged pool, and kernel session pool (for a description of kernel memory pools, see the section “Kernel-Mode Heaps (System Memory Pools).”
However, on 32-bit Windows, execution protection is applied only to thread stacks and user-mode pages, not to paged pool and session pool.
Properties, Advanced System Settings, Performance Settings. (See Figure 10-2.) When you configure no execute protection in the Performance Options dialog box, the BCD nx option is set to the appropriate value. Table 10-3 lists the variations of the values and how they correspond to the DEP settings tab. The registry lists 32-bit applications that are excluded from execution protection under the key
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AppCompatFlags\Layers, with the value name being the full path of the executable and the data set to “DisableNXShowUI”.
当您在性能选项对话框中配置不可执行保护时，BCD nx 选项会被设置成相应的值。表10-3列出了它的取值，以及相应的DEP设置。在注册表键 HKLM\SOFTWARE\Microsoft\Windows NT
\CurrentVersion\AppCompatFlags\Layers 下，列出了排除在执行保护外的32位应用程序，其键值包含被排除在外的可执行文件完整路径，并且其“数值数据”被设置为“DisableNXShowUI”。
On Windows server systems, execution protection for 32-bit applications is configured by default to apply to all 32-bit programs (the nx BCD option is set to OptOut).
will verify the signature of the executable against known copy-protection mechanisms (such as SafeDisc and SecuROM) and disable execution protection to provide compatibility with older copyprotected software such as computer games.
Process Explorer can show you the current DEP status for all the processes on your system,including whether the process is opted in or benefiting from permanent protection. To look at the DEP status for processes, right-click any column in the process tree, choose Select Columns, and then select DEP Status on the Process Image tab. Three values are possible:
■ DEP (permanent) This means that the process has DEP enabled because it is a “necessary Windows program or service.”
■ DEP This means that the process opted in to DEP. This may be due to a systemwide
policy to opt in all 32-bit processes, an API call such as SetProcessDEPPolicy, or setting the linker flag /NXCOMPAT when the image was built.
■ Nothing If the column displays no information for this process, DEP is disabled, either because of a systemwide policy or an explicit API call or shim.
进程浏览器可以显示您系统上所有进程的当前DEP状态，包括进程是否已选择加入，或受益于永久性DEP。要查看进程的DEP状态，在进程浏览器主界面进程数列表的任意列上右击，“选择列”，在打开的对话框中切换到“Process Image”选项卡，勾选其中的“DEP Status”复选框即可。可能的取值有3种：
■ DEP（永久性） 表示该进程启用了DEP，因为它是一个“必要的”Windows程序或服务。
■ DEP 表示该进程“选择加入”DEP，这可能是由于选择了所有32位进程的系统级策略导致的，例如对SetProcessDEPPolicy API函数的调用（动态DEP配置），或者在构建该进程对应的映像文件时，设置了/NXCOMPAT 链接器标志（静态DEP配置）。（译注：设置方法参考下图）
■ Nothing 如果进程的DEP状态列没有显示任何信息，表示禁用了DEP，这要么是因为一个系统级的策略，要么是一个显式的 API 调用导致的。（译注：最后的单词shim不知作何解释）
show simply DEP, meaning that DEP can be turned off for them via the dialog box shown in Figure 10-2. The other processes shown are running Windows in-box programs and show DEP (Permanent), indicating that DEP cannot be disabled for them.
This environment detects ATL thunk code sequences that have caused the DEP exception and emulates the expected operation. Application developers can request that ATL thunk emulation not be applied by using the latest Microsoft C++ compiler and specifying the /NXCOMPAT flag (which sets the IMAGE_DLLCHARACTERISTICS_NX_COMPAT flag in the PE header), which tells the system that the executable fully supports DEP. Note that ATL thunk emulation is permanently disabled if the AlwaysOn value is set.
This function can also be used to dynamically disable ATL thunk emulation in case the image wasn’t compiled with the /NXCOMPAT flag. On 64-bit processes or systems booted with AlwaysOff or AlwaysOn, the function always returns a failure. The GetProcessDEPPolicy function returns the 32-bit per-process DEP policy (it fails on 64-bit systems, where the policy is always the same—enabled),
while GetSystemDEPPolicy can be used to return a value corresponding to the policies in Table 10-3.
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]BOOL WINAPI SetProcessDEPPolicy(__in DWORD dwFlags);[/COLOR][/SIZE][/FONT]
如果 dwFlags 的值为1，则在进程生命周期内永久启用DEP。
对于64位进程，或者系统以AlwaysOff/AlwaysOn 选项启动，则该函数总是返回失败。函数GetProcessDEPPolicy返回每个32位进程的DEP策略（在64位系统上调用此函数会失败，因为此时DEP策略总是“启用”），而函数GetSystemDEPPolicy可用于返回（查询）与表10-3中列出策略相对应的值。
For older processors that do not support hardware no execute protection, Windows supports limited software data execution prevention (DEP). One aspect of software DEP reduces exploits of the exception handling mechanism in Windows. (See Chapter 3 in Part 1 for a description of structured exception handling.) If the program’s image files are built with safe structured exception handling (a feature in the Microsoft Visual C++ compiler that is enabled with the /SAFESEH flag), before an exception is dispatched, the system verifies that the exception handler is registered in the function table
(built by the compiler) located within the image file.
对于不支持硬件不可执行保护的较早处理器，Windows也提供了有限的软件数据执行保护（DEP）。软件DEP的一个方面是减少对Windows中异常处理机制的漏洞利用可能性。（参见本书上册第3章对结构化异常处理的介绍。）如果程序的二进制映像文件通过安全的结构化异常处理（Microsoft Visual C++ 编译器中的一个功能，通过 /SAFESEH 标志启用）构建，在分发一个异常前，系统会验证该异常处理程序是否在位于映像文件内的函数表（由编译器构建）中注册。
（译注：下图给出在 Visual Studio 2010 中，对欲构建的PE文件，配置启用/SAFESEH 标志的方法。）
在 VS 2015 中，改选项的中文解释大致相同：
Overwrite Protection (SEHOP). A new symbolic exception registration record is added on the stack when a thread first begins user-mode execution. The normal exception registration chain will lead to this record. When an exception occurs, the exception dispatcher will first walk the list of exception handler registration records to ensure that the chain leads to this symbolic record. If it does not, the exception chain must have been corrupted (either accidentally or deliberately), and the exception dispatcher
will simply terminate the process without calling any of the exception handlers described on the stack. Address Space Layout Randomization (ASLR) contributes to the robustness of this method by making it more difficult for attacking code to know the location of the function pointed to by the symbolic exception registration record, and so to construct a fake symbolic record of its own.
当一个线程首次开始在用户模式执行时，一个新的符号异常注册记录被加入到栈上。普通的异常注册链将指向（lead to）此记录。当发生一个异常时，异常分发器将首先遍历（walk）异常处理程序注册记录列表，确保该链连接到此符号记录。如果不是这样，该异常链必定已损坏（不是无意就是有意），此时异常分发器将仅仅终止进程，不会调用任何栈上描述的异常处理程序。地址空间布局随机化（ASLR）技术，通过符号异常注册记录让攻击代码更难于得知函数指向的位置，以及构造一个自身的假符号记录。这有助于此方法（译注：即异常分发器检查符号记录决定是否调用异常处理程序）的健壮性。
since some DLLs might have exception handlers that were set up by the main executable, which is why this mitigation is off by default). Finally, Executable Dispatch Mitigation further makes sure that the SEH handler is located within an executable page—a less strong requirement than Image Dispatch Mitigation, but one with fewer compatibility issues.
The first relies on the compiler to insert special code at the beginning and end of each potentially exploitable function. The code saves a special numerical value (the cookie) on the stack on entry and validates the cookie’s value before returning to the caller saved on the stack (which would have now been corrupted to point to a piece of malicious code). If the cookie value is mismatched, the application is terminated and not allowed to continue executing. The cookie value is computed for each boot when executing the first user-mode thread, and it is saved in the KUSER_SHARED_DATA structure. The image loader reads this value and initializes it when a process starts executing in user mode. (See Chapter 3 in Part 1 for more information on the shared data section and the image loader.)
每次系统启动，执行首个用户模式线程时，都计算该cookie值，并且保存在KUSER_SHARED_DATA结构体中。当一个进程开始在用户模式中执行时，映像加载器读取该值并对其进行初始化。（参见本书上册第3章有关共享数据节和映像加载器的更多内容）
（译注：栈cookies 通过设置 Visual C/C++ 编译器的 /GS 编译选项来实现，具体参考下图）
（要自行研究栈 cookies的内部机制也非常容易，只要以IDA等工具反汇编通过启用/GS 编译选项构建的PE文件即可，另外，在源代码的开头添加如下指令，可以让编译器在绝大多数的例程中添加 cookie）
[FONT="微软雅黑"][SIZE="4"][COLOR="Black"]#pragma strict_gs_check(on)[/COLOR][/SIZE][/FONT]
attempt to decode the pointer, resulting in a corrupted value and causing the program to crash. The EncodePointer and DecodePointer APIs provide similar protection but with a per-process cookie (created on demand) instead of a per-system cookie.
1。首先在进程浏览器中，查看 Visual Studio 2010 主进程 devenv.exe 的 DEP 状态为“永久启用”（permanent），如下所示：
2。启动 KD.exe，执行 !process 0 0 devenv.exe 命令，列出进程的 EPROCESS 结构信息，然后显式设置调试上下文为该进程：
3。由于每个进程的 EPROCESS 结构（执行体进程块）中的第一个成员就是 KPROCESS 结构（内核进程块），而 KPROCESS 结构中的 KEXECUTE_OPTIONS 结构，存储了该进程的 DEP 信息，因此，我们可以使用 dt nt!_KPROCESS 命令，后面直接带 EPROCESS 结构的线性地址，然后加上 -r 开关，递归遍历其中的所有成员，从而找出 KEXECUTE_OPTIONS 结构：
Copy-on-write page protection is an optimization the memory manager uses to conserve physical memory. When a process maps a copy-on-write view of a section object that contains read/write pages, instead of making a process private copy at the time the view is mapped, the memory manager defers making a copy of the pages until the page is written to. For example, as shown in Figure 10-3, two processes are sharing three pages, each marked copy-on-write, but neither of the two processes has attempted to modify any data on the pages.
写时复制页面保护是内存管理器用于节约物理内存的一种优化手段。既然一个进程映射一个包含读/写页节对象的写时复制视图，而不是在当时创建一个进程私有的副本视图来映射，那么内存管理器将推迟创建该页的私有副本，直到该页被写入。如下图10-3所示，在2个进程之间共享3个页面，每个页面都被标记为写时复制，但是这2个进程都没有尝试修改这些页中的任何数据。
causing the instruction that generated the fault to be reexecuted. This time, the write operation succeeds, but as shown in Figure 10-4, the newly copied page is now private to the process that did the writing and isn’t visible to the other process still sharing the copy-on-write page. Each new process that writes to that same shared page will also get its own private copy.
Copy-on-write is one example of an evaluation technique known as lazy evaluation that the memory manager uses as often as possible. Lazy-evaluation algorithms avoid performing an expensive operation until absolutely required—if the operation is never required, no time is wasted on it.
To examine the rate of copy-on-write faults, see the performance counter Memory: Write Copies/sec.
Although the 32-bit version of Windows can support up to 64 GB of physical memory (as shown in Table 2-2 in Part 1), each 32-bit user process has by default only a 2-GB virtual address space. (This can be configured up to 3 GB when using the increaseuserva BCD option, described in the upcoming section “User Address Space Layout.”) An application that needs to make more than 2 GB (or 3 GB) of data easily available in a single process could do so via file mapping, remapping a part of its address space into various portions of a large file. However, significant paging would be involved upon each remap.
For higher performance (and also more fine-grained control), Windows provides a set of functions called Address Windowing Extensions (AWE). These functions allow a process to allocate more physical memory than can be represented in its virtual address space. It then can access the physical memory by mapping a portion of its virtual address space into selected portions of the physical memory at various times.
尽管Windows的32位版本能够支持最多64GB的物理内存（如本书上册表2-2所示），每个32位用户模式进程默认情况只有一个2GB的虚拟地址空间。（使用 increaseuserva BCD 选项时，可以配置成最多3GB，本章后面的“用户地址空间布局”小节即将对此进行论述。）一个需要使用或产生多于2GB（或3GB）数据的应用程序通过文件映射，即可在单一进程中轻易获得这样的空间分配，重新将自身地址空间的一部分映射到一个大型文件的各个部分。然而，每个重映射过程都将涉及显式分页。为了提高性能（以及更多细粒度的控制），Windows提供了一组叫做地址窗口化扩展（AWE）的函数。这些函数允许分配给一个进程的物理内存超过能够代表进程自身虚拟地址空间的物理内存。（译注：AWE函数的原型声明在 winbase.h 头文件中。这些 API 允许程序访问的物理内存总量大于它的线性地址空间对其限定的物理内存量；“线性地址”是英特尔文档中的用语，微软将其称为“虚拟地址”，在处理器启用分段与分页的多数场景下，将虚拟地址进行第一阶段分段，得到线性地址；将线性地址进行第二阶段分页，得到物理地址，这就是地址翻译的过程；在仅启用分页的情况下，一般可以认为虚拟地址就是线性地址。）
接着，在不同时间点上，进程都可以通过将自身虚拟地址空间的一部分映射到选定部分的物理内存，来对其进行访问。
（译注：increaseuserva BCD 选项的设置方法如下图所示）
1. Allocating the physical memory to be used. The application uses the Windows functions AllocateUserPhysicalPages or AllocateUserPhysicalPagesNuma. (These require the Lock Pages In Memory user right.)
2. Creating one or more regions of virtual address space to act as windows to map views of the physical memory. The application uses the Win32 VirtualAlloc, VirtualAllocEx, or VirtualAllocExNuma function with the MEM_PHYSICAL flag.
3. The preceding steps are, generally speaking, initialization steps. To actually use the memory, the application uses MapUserPhysicalPages or MapUserPhysicalPagesScatter to map a portion of the physical region allocated in step 1 into one of the virtual regions, or windows, allocated in step 2.
1. 分配要使用的物理内存。应用程序使用Windows函数AllocateUserPhysicalPages 或 AllocateUserPhysicalPagesNuma（这要求调用方具有内存中锁定页面的用户权限）。
（译注：这是由于后文将提及的：通过AWE分配的物理内存永远不会换出到磁盘，必须锁定在内存中，因此调用AWE函数的应用程序需要获得“锁定内存页”权限）
2. 创建一个或者更多的虚拟地址空间区域，作为要映射物理内存视图的窗口（译注：原文中的windows为小写，因此假定作者原意指窗口，而非Windows操作系统）。应用程序使用Win32 API 函数VirtualAlloc，VirtualAllocEx，或者 VirtualAllocExNuma，并且指定 MEM_PHYSICAL 标志。
3. 一般而言，前面2步为初始化操作。为了实际使用内存，应用程序需要 MapUserPhysicalPages 或 MapUserPhysicalPagesScatter函数，来将第1步分配的一部分物理区域映射到第2步分配的其中一个虚拟区域或窗口。
It can then use MapUserPhysicalPages or MapUserPhysicalPagesScatter to access any portion of the physical memory by mapping the desired portion of memory into the 256-MB window. The size of the application’s virtual address space window determines the amount of physical memory that the application can access with any given mapping. To access another portion of the allocated RAM, the application can simply remap the area.
never paged out, the data in AWE memory can never have a copy in the paging file that someone could examine by rebooting into an alternate operating system. (VirtualLock provides the same guarantee for pages in general.)
■ Pages can’t be shared between processes.
■ The same physical page can’t be mapped to more than one virtual address in the same process.
■ Page protection is limited to read/write, read-only, and no access.
■ 页面不能在进程间共享；
■ 相同的物理页只能被映射到同一个进程中的单个虚拟地址窗口（即多个虚拟地址窗口不能映射相同的物理页，参考图10-5很容易理解）
■ AWE的页面保护选项被限制为：读/写，只读，以及不允许访问。
Therefore, AWE is not necessary to allow an application to use more RAM than it has virtual address space; the amount of RAM on the system will always be smaller than the process virtual address space. AWE remains useful, however, for setting up nonpageable regions of a process address space. It provides finer granularity than the file mapping APIs (the system page size, 4 KB or 8 KB, versus 64 KB).
For a description of the page table data structures used to map memory on systems with more than 4 GB of physical memory, see the section “Physical Address Extension (PAE).”
在这方面，AWE提供比文件映射 APIs 更细的粒度（AWE提供 4KB 或 8KB 的系统页尺寸分配粒度，而文件映射 APIs 只能基于 64KB 边界对齐的分配粒度）。
参见本章“物理地址扩展”一节，其中讨论了带有4GB以上物理内存的系统用于映射内存的页表数据结构。
|
|
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
可能是下册的翻译难度更大一些，没官方翻译我们只有自力更生翻译了
|
|
|
|
