64位IIS环境.Net应用占2.8GB内存时触发OutOfMemory异常咨询

以下原因按生产环境出现概率从高到低排序：

• IIS应用池32位模式误开启：这是和描述中2.8GB触发阈值最匹配的高频故障点。即使应用本身编译为64位/Any CPU目标，只要对应IIS应用池高级设置中「启用32位应用程序」配置为True，w3wp工作进程就会以32位模式运行，32位Windows进程的用户态可用寻址空间上限通常为2~3GB，触达阈值后就会抛出OOM，和服务器总物理内存、页面文件剩余大小完全无关。可以直接在任务管理器详情页查看对应w3wp进程名后是否带*32后缀确认，修正配置为False后重启应用池即可恢复。
• IIS应用池内存回收阈值配置错误：IIS支持对每个应用池单独配置专用内存、虚拟内存回收阈值，不少运维会沿用32位时代的旧配置，把阈值设为3000000KB（约2.86GB）。当进程内存触达该阈值时，IIS会直接向运行时注入内存不足信号触发OOM，而非先执行进程回收。可以打开对应应用池的「高级设置-回收」板块核查，无特殊需求建议将两个内存限制值设为0，即不基于内存占用做强制回收。
• 托管堆碎片化导致连续内存分配失败：.Net运行时抛出OOM的判定逻辑从来不是进程总内存占用触达上限，而是申请指定大小的连续内存块失败。.Net Framework 4.8默认不会对大对象堆（LOH，存储所有大于85KB的分配对象）做自动内存压缩，如果代码中频繁分配、释放大对象（比如大文件全量读入内存、超大数组、大尺寸序列化缓冲），很容易在LOH中产生大量零散内存空隙，当某次申请需要一块大尺寸连续内存时，哪怕进程总占用只有2.8GB，也会因为找不到符合要求的连续内存块抛出OOM。故障时抓进程dump用PerfView或WinDbg查看LOH碎片率，若碎片率超过40%即可确认根因，可通过配置开启LOH定期压缩临时缓解，长期需要优化代码减少大对象的重复分配。
• 非托管资源占用导致虚拟地址空间不足：部署的是基于.Net Framework 4.8承载的.Net Core应用，属于混合模式运行进程，如果加载了老旧的非托管COM组件、C++编写的原生类库，或者存在GDI+资源、句柄、非托管内存泄漏的问题，会提前占用大量进程虚拟地址空间预留段，导致托管GC无法申请到足够的连续虚拟内存段扩容，即使物理内存剩余充足也会触发OOM。
• 系统层面单进程内存配额限制：部分做过安全加固的Windows服务器会通过组策略、Windows系统资源管理器给w3wp这类服务进程配置单进程内存使用上限，如果上限被设为3GB左右，触达阈值时同样会抛出内存不足错误，和全局内存剩余量无关。

补充纠正一个认知偏差：64位.Net应用的理论寻址上限确实可达8TB，但这个上限是建立在进程无配额限制、虚拟地址空间连续可用的前提下，任何一层配置限制、内存碎片问题都会让实际可分配内存远低于理论值。

内容的提问来源于stack exchange，提问作者JRS