我正在集群上运行我的代码，并且看到一个我无法在本地复制的问题，而且没有看到原因。
所以，程序开始在整个代码中随意的抛出OutOfMemoryExceptionexception。
此外，看起来这可能与Windows本身已经破坏的东西有关 – 其中一个exceptionperformance为Assembly.Load操作的HRESULT，HRESULT为0x800705AF，解码时表示错误1455 ERROR_COMMITMENT_LIMIT（交换文件筋疲力尽） 。
该程序实际上消耗了非常less量的内存，它是32位，在.NET 4.0.30319下运行，服务器是Windows Server 2008，有12个核心，24Gb RAM（几乎全部空闲）和几十吉字节的交换分区上的可用硬盘空间。
我怎样才能debugging这个错误的原因呢？ 使用哪些诊断工具？
这是一个64位进程在内存不足的情况下死亡的方式。 要小心你所看到的诊断。 它永远不会耗尽内存，它是虚拟内存空间。 您必须查看像VM大小或专用字节的数字，任务管理器过于集中于RAM。
一个64位的进程有一个巨大的虚拟内存空间，16千兆字节以上，这取决于你运行的Windows版本。 完全使用它是不可能的，机器会死亡，然后才能关闭。 哪个操作系统当然不允许发生，因此ERROR_COMMITMENT_LIMIT。 实际上，64位进程受到页面文件中可以保留的空间量的限制。
使用像SysInternals的进程资源管理器的工具有另一个样子。 内存分析器，当你看到虚拟内存大小无限增长。
首先检查您的应用程序是否在32位或64位模式下运行，如果您的应用程序有* 32，则表示在32位以下运行，请查看taskmanager。 32位应用程序只有2GB的虚拟地址空间供您的应用程序使用。 而当操作系统找不到足够的连续地址来满足您的应用程序内存请求时，会发生OOM。 所以要找出问题，我会建议阅读文章http://www.codeproject.com/Articles/176031/Out-of-Memory-Exception-A-simple-string-Split-can-.aspx 。 如果上面的文章没有解决你的问题，那么你可以参考http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx 。