windows - 对 32 位 Windows 可执行文件使用/LARGEADDRESSAWARE 的缺点？

Question

我们需要将我们的一个可执行文件与此标志相关联，因为它会占用大量内存。
但是为什么要给一个EXE文件特殊处理呢。为什么不对 /LARGEADDRESSAWARE 进行标准化？

所以问题是:使用 /LARGEADDRESSAWARE 有什么问题，即使您不需要它。为什么不将它用作所有 EXE 文件的标准？

Answer 1

盲目地将 LargeAddressAware 标志应用于 32 位可执行文件会部署定时炸弹!

通过设置此标志您正在向操作系统作证:

yes, my application (and all DLLs being loaded during runtime) can cope with memory addresses up to 4 GB.
so don't restrict the VAS for the process to 2 GB but unlock the full range (of 4 GB)".

但你真的能保证吗？
您是否对您的进程可能使用的所有系统 DLL、Microsoft 可再发行组件和第 3 方模块负责？

通常，内存分配按从低到高的顺序返回虚拟地址。因此，除非您的进程消耗大量内存(或者它具有非常碎片化的虚拟地址空间)，否则它永远不会使用超过 2 GB 边界的地址。这是隐藏与高地址相关的错误。

如果存在此类错误，则很难识别。他们会“迟早”偶尔出现。这只是时间问题。

幸运的是，Windows 操作系统内置了一个非常方便的系统范围开关:
出于测试目的，请使用 MEM_TOP_DOWN 注册表设置。
这会强制所有内存分配自上而下，而不是正常的自下而上。

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management]
"AllocationPreference"=dword:00100000

(这是十六进制 0x100000。当然需要重新启动 Windows)

启用此开关后，您将“更快”而不是“稍后”发现问题。理想情况下，您会“从一开始”就看到它们。

附注:对于第一次分析，我强烈推荐工具 VMmap (SysInternals)。

结论:

将 LAA 标志应用于 32 位可执行文件时，必须在 x64 操作系统上使用 TopDown AllocationPreference 开关集对其进行全面测试。

对于您自己的代码中的问题，您或许可以修复它们。
举一个非常明显的例子:使用无符号整数而不是有符号整数作为内存指针。

当遇到 3rd-party 模块的问题时，您需要请求作者修复他的错误。除非这样做，否则最好从可执行文件中删除 LargeAddressAware 标志。

---

关于测试的说明:

MemTopDown 注册表开关未达到单元测试的预期结果，这些测试由本身未启用 LAA 的“测试运行器”执行。
见:Unit Testing for x86 LargeAddressAware compatibility

---

PS:
从 32 位代码到 64 位的迁移也是非常“相关”且非常有趣的。
示例见:

• As a programmer, what do I need to worry about when moving to 64-bit windows?
• https://www.sec.cs.tu-bs.de/pubs/2016-ccs.pdf (双倍的麻烦，双倍的麻烦)