结合你提到的场景（64位Win10、32位C#程序、启用LARGE_ADDRESS_AWARE后内存上限从1GB提升至1.5GB），除了LAA标志外，还有不少关键因素会限制你的进程内存使用，我给你逐一拆解：

• .NET GC堆的碎片化问题
  这是32位程序里最常见的隐形内存杀手之一。.NET的大对象堆（LOH，用于存放超过85KB的对象）默认不会自动压缩（直到.NET 4.5.1才支持手动触发压缩）。如果你加载3D模型时频繁创建和释放大对象（比如模型的顶点数据、纹理缓冲区），LOH会很快产生大量内存碎片——哪怕进程总内存占用还没到上限，也找不到连续的大块空间来分配新的大对象，直接抛出OutOfMemoryException。

• 32位进程的地址空间分配限制
  即使开了LARGE_ADDRESS_AWARE，64位Windows上的32位进程最多能拿到3GB的用户态地址空间（默认是2GB），但这3GB不是全部留给.NET堆的：

  • 系统DLL、第三方库会加载到进程的地址空间里，占用一部分；
  • 每个线程的栈空间（默认1MB/线程）、内存映射文件、共享内存等也会瓜分地址空间；
    这些额外的占用会压缩.NET堆的可用空间，这也是你现在只能用到1.5GB的原因之一。

• .NET运行时的内置限制

  • 默认情况下，.NET对单个数组的大小有严格限制：一维数组最多占用2GB，多维数组的总字节数也不能超过2GB。如果你的3D模型数据是用超大数组存储的，就算总内存够，也会触发OOM。可以在app.config里添加<gcAllowVeryLargeObjects enabled="true" />来解除这个限制（需要.NET 4.5及以上，VS2013对应的.NET版本支持这个配置）。
  • 如果你手动配置过maxHeapSize这类参数，也会直接限制.NET堆的最大可用空间。

• 非托管内存的抢占
  加载3D模型通常会用到非托管代码（比如原生3D引擎、DirectX API），这些非托管内存的分配是直接占用进程地址空间的，而且不受.NET GC管理。如果非托管代码已经占用了大量地址空间（比如1GB），那.NET堆的可用空间就会被压缩，导致进程总内存还没到3GB就OOM。另外，非托管内存泄漏也会快速耗尽地址空间，要注意检查这部分代码的内存释放逻辑。

• 系统虚拟内存的配置
  虽然你有8GB物理内存，但如果Windows的页面文件（虚拟内存）设置得太小，或者被禁用，当进程需要的虚拟内存超过物理内存+页面文件的总可用量时，也会触发OOM。不过这个情况在32位进程里相对少见，但极端情况下也会影响。

• 调试环境的额外开销
  当你在Visual Studio里调试程序时，调试器会占用一部分进程地址空间来存储调试信息、断点数据等，这会导致调试时的可用内存比直接运行发布版程序要少。可以试试直接运行编译好的exe文件，看看内存上限会不会有所提升。

内容的提问来源于stack exchange，提问作者Shan-Hung Hsu