对32位Windows可执行文件使用/largeaddressware的缺点?

盲目应用 LargeAddressAware 定时炸弹 !

通过设置此标志

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

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

如果存在这样的错误,它们很难识别。他们迟早会偶尔出现。只是时间问题。

幸运的是,windows操作系统内置了一个非常方便的全系统交换机:
出于测试目的,请使用MEM\u TOP\u DOWN注册表设置。
这将强制所有内存分配从上到下,而不是正常的自下而上。

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

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

启用此开关后,您将“更快”而不是“更晚”确定问题。

旁注:对于第一个分析,我强烈推荐这个工具 VMmap ( SysInternals ).

结论:

将LAA标志应用于32位可执行文件时,必须在x64操作系统上以自顶向下的方式对其进行完全测试 AllocationPreference 开关组。

中的问题 你也许能修好它们。
举一个非常明显的例子:对内存指针使用无符号整数而不是有符号整数。

遇到问题时 第三方

测试注意事项:

单元测试 不 LAA已启用。
Unit Testing for x86 LargeAddressAware compatibility

附言:

有关示例,请参见:

• 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 (两倍的比特,两倍的麻烦)

因此,微软更容易做到安全,并且需要(a)需要完整的4Gb和(b)已经在大内存场景中开发和测试的应用程序,只需设置标志。

正如你所注意到的,这并不难。

雷蒙德陈-在他的博客 The Old New Thing

不,在这种上下文(C/C++)中,“遗留代码”并不是唯一一种对指针的MSB进行恶作剧的代码。

它还包括所有使用“int”来存储两个指针之间的差异或内存区域长度的代码,而不是使用正确的类型“size\t”:“int”被签名有31位,并且不能处理超过2GB的值。

修复代码的一个很好的部分的方法是检查并纠正它 全部的

显然地 即使你什么也不改正,也要坚持一段时间。

只有在一个块中分配超过2GB时,才会中断。或者当您比较两个彼此相距超过2GB的不相关指针时。
由于比较不相关的指针在技术上是一种未定义的行为,因此您不会遇到太多这样做的代码(但您永远无法确定)。
而且很常见的情况是,即使您总共需要超过2Gb的内存,您的程序实际上从来不会进行大于2Gb的单个分配。事实上,在Windows中,即使使用LARGEADDRESSAWARE,根据内存的组织方式,默认情况下也无法分配那么多内存。您需要对系统DLL进行洗牌,以获得超过2Gb的连续块

将 有一天,它只是,它会发生很长时间后,你启用了没有检查LargeAddressware,当没有人会记得这已经做了。