我正在努力诊断OutOfMemoryException我们的应用程序中的一系列问题。这是一个内部 32 位 (x86) OWIN 托管的 WebAPI，它在控制台应用程序中运行，并与一系列硬件组件并行通信。出于这个原因，它创建了大约 20 个库实例，并且在创建这些实例时，“虚拟大小”内存的急剧增加相匹配。
从 Process Explorer 和 dotMemory 的输出来看，我们似乎并未在此应用程序中分配那么多实际内存：
通过阅读许多 SO 答案，我想我明白我们的问题是来自 G0、G1、G2 和 LOH 堆中的碎片，或者我们可能遇到了在 Windows 上运行的 32 位进程的 2GB 可寻址内存限制7. 此应用程序分批工作，它从硬件设备收集一堆数据，在内存中创建集合以将这些数据聚合到单个对象中，然后将其保存以供客户端应用程序检索。此活动是 dotMemory 视觉效果出现峰值的原因，但这些数据结构并不庞大，我认为 dotMemory 图表显示了这一点。
查看堆显示它们的大小很少超过 10-15MB，而且我没有看到太多证据表明 LOH 变得太大或严重分散。我真的很挣扎如何继续更好地了解这里发生的事情。
所以我的问题有两个：
是否可以想象我们可能会达到 2GB 的虚拟内存限制，而这是导致这些内存异常的原因？
如果这是一个可能的原因，那么我认为 64 位构建可以解决这个问题是否正确？
我们正在探索转向 64 位构建，但这需要将我们使用的一些低级库更新为 64 位。这当然是我们最终会探索的一个选项（如果不是更早的话），但我们会在投入所需时间之前尝试更好地了解这种情况。
设置 LARGEADDRESSFLAG 后更新
根据建议，我在二进制文件上设置了该标志，有趣的是，虚拟大小立即跃升至近 3GB。我不知道我是否应该对此感到震惊？！
在接下来的几个小时内，我将使用此配置监视应用程序。