Windows 关于内存页保护的问题

这是我在阅读《Windows via C/C++5th Edition》时遇到的另一个问题。首先，让我们看一些引文

LPVOID WINAPI VirtualAlloc(
  __in_opt  LPVOID lpAddress,
  __in      SIZE_T dwSize,
  __in      DWORD fdwAllocationType,
  __in      DWORD fdwProtect
);

最后一个参数fdwProtect， 指示保护属性 这应该分配给该区域。 与区域关联的保护属性对区域没有影响 已提交的存储映射到 地区。

保留区域时，指定将使用的保护属性 最常见的情况是存储已提交 到区域。例如，如果 打算使用提交物理存储 保护属性 PAGE_READWRITE，您应该保留 具有页面_READWRITE的区域最新版本 系统的内部记录保存 当 区域的保护属性匹配 承诺存储的保护 属性。

（提交存储时）…您通常 通过相同的页面保护 属性时使用的 VirtualAlloc被叫去预订 区域，，尽管您可以指定 不同的保护属性。

上面的引语完全把我弄糊涂了

• 如果与区域关联的保护属性对提交的存储没有影响，为什么需要它

• 既然建议在保留和提交时使用相同的保护属性，为什么Windows仍然为我们提供使用不同属性的选项？这不是一种错误的引导和矛盾吗

• 保留区域和提交存储的保护属性分别存储在哪里

---

非常感谢您的见解。

好吧。。。一个原因可能是您可以使用保护页，以便在使用内存时提交内存

想想Windows中的线程堆栈；堆栈正下方的页面被设置为保护页面，通常具有读写功能。一旦触及保护页，异常处理程序就会运行并提交保护页，并使下一页成为保护页

有关更好的描述，请参阅。此外，该链接是关于windows如何处理低级资源的系列文章的一部分，非常适合阅读

允许您重新指定保护属性的另一个原因可能是写时复制技术。页面被设置为只读，直到它们被更改，这会引发一个您可以处理的异常等

在386系列英特尔芯片上，提交、读/写/保留标志存储在页表中。有关更多详细信息，请参阅。 编辑：我翻了一下，找不到MS存储页面保护位的位置。现在我很好奇我在哪里看到的。：）可惜去年春天我扔掉了大约500磅的旧参考资料

---

希望这有帮助：）

好吧。。。一个原因可能是您可以使用保护页，以便在使用内存时提交内存

想想Windows中的线程堆栈；堆栈正下方的页面被设置为保护页面，通常具有读写功能。一旦触及保护页，异常处理程序就会运行并提交保护页，并使下一页成为保护页

有关更好的描述，请参阅。此外，该链接是关于windows如何处理低级资源的系列文章的一部分，非常适合阅读

允许您重新指定保护属性的另一个原因可能是写时复制技术。页面被设置为只读，直到它们被更改，这会引发一个您可以处理的异常等

在386系列英特尔芯片上，提交、读/写/保留标志存储在页表中。有关更多详细信息，请参阅。 编辑：我翻了一下，找不到MS存储页面保护位的位置。现在我很好奇我在哪里看到的。：）可惜去年春天我扔掉了大约500磅的旧参考资料

---

希望这有帮助：）

在上下文中阅读它很重要

关联的保护属性 与该地区没有任何影响 已提交的存储映射到 地区

指的是保留，而不是提交区域

保留页没有后备存储，因此从概念上讲，它的保护始终是page\u NOACCESS。即，如果线程试图读/写保留区域中的地址，则会引发访问冲突

从链接文章：

保留地址始终为空 PAGE_NOACCESS，由强制执行的默认值 无论价值是什么，系统都是有效的 传递给函数。坚信的 页面可以是只读的， 读写或无访问权限

关于：

• 保护到底在哪里 为保留区域存储的属性 和提交存储，分别是

每个进程的虚拟地址区域的保护属性存储在VAD树中。（VAD==虚拟地址描述符，请参阅或链接文章）

既然建议在保留和提交时使用相同的保护属性，为什么Windows仍然为我们提供使用不同属性的选项？这不是一种错误的引导和矛盾吗

因为函数始终接受保护参数，但其行为取决于

fdwAllocationType

。保护仅适用于提交的存储

里克特建议使用相同的保护设置的原因大概是因为一个区域中保护标志的变化越少，意味着“块”就越少（定义见您的书），因此VAD的AVL树越小。也就是说，如果一个区域中的所有页面都使用相同的标志提交，那么只有一个块。否则，该区域中的块数可能与页面数相同。每个块（不是页面）都需要VAD

Block==具有相同保护/状态的连续页面集

如果保护属性与 与该地区没有任何影响 委员会