我正在集群上运行代码，发现无法在本地复制的问题，并且看不到原因。
因此，程序开始在整个代码的随机位置虚假地抛出 OutOfMemoryException。
此外，看起来这可能与 Windows 本身的某些问题有关 - 其中一个异常表现为 Assembly.Load 操作的 HRESULT，HRESULT 为 0x800705AF，解码后意味着错误 1455 ERROR_COMMITMENT_LIMIT（交换文件已耗尽）。
该程序实际上消耗的内存非常少，它是32位的，在.NET 4.0.30319下运行，服务器是Windows Server 2008，12核，24Gb RAM（几乎全部免费）和几十GB交换分区上的可用硬盘空间。
我怎样才能调试这个错误的原因呢？使用什么诊断工具？
I'm running my code on a cluster and I'm seeing a problem that I cannot replicate locally, and do not see the reason for.
So, the program starts spuriously throwing OutOfMemoryException's in random places all over the code.
Moreover, looks like this might have to do with something having broken in Windows itself - one of those exceptions manifested itself as an HRESULT of an Assembly.Load operation, with the HRESULT being 0x800705AF, which, when decoded, means error 1455 ERROR_COMMITMENT_LIMIT (swapfile exhausted).
The program actually consumes a very small amount of memory, it is 32-bit, runs under .NET 4.0.30319, and the server is Windows Server 2008, with 12 cores, 24Gb RAM (almost all of which free) and several dozen gigabytes of free hard drive space on the swap partition.
How can I debug the reason for this error at all? What diagnostic tools to use?
发布评论
评论（2）
这就是 64 位进程在内存不足的情况下终止的方式。诊断此问题时要小心观察。您永远不会用完 RAM，它是虚拟内存空间。您必须查看虚拟机大小或专用字节等数字，任务管理器过于关注 RAM。
64 位进程拥有巨大的虚拟内存空间，可达 16 GB 及以上，具体取决于您运行的 Windows 版本。不可能完全用完，在你接近之前机器就死掉了。操作系统当然不允许这种情况发生，因此出现 ERROR_COMMITMENT_LIMIT。实际上，64 位进程受到其可以在分页文件中保留的空间量的限制。
使用 SysInternals 的 Process Explorer 等工具进行另一种查看。当您确实看到虚拟内存大小无限增长时，使用内存分析器。
This is the way a 64-bit process dies on a out-of-memory condition. Be careful at what you look at to diagnose this. It is never RAM that you run out of, it is virtual memory space. You have to look at a number like VM-size or Private Bytes, Task Manager focuses too much on RAM.
A 64-bit process has an enormous virtual memory space, 16 gigabytes and up, depending on what version of Windows you run on. It is impossible to completely use it up, the machine dies a swapping death before you can get close. Which of course the operating system cannot allow to happen, thus ERROR_COMMITMENT_LIMIT. In practice, a 64-bit process is limited by the amount of space it can reserve in the paging file.
Use a tool like SysInternals' Process Explorer to have another look. A memory profiler when you do see virtual memory size growing without bound.
首先检查您的应用程序是否在32位或64位模式下运行，在任务管理器中查看您的应用程序是否最后有*32，这意味着它在32位下运行。 32 位应用程序只有 2GB 的虚拟地址空间供您的应用程序使用。当操作系统无法找到足够的连续地址来满足您的应用程序内存请求时，就会发生 OOM。因此，为了确定问题，我建议阅读文章 http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx< /a>.
First check if your application is running under 32 or 64 bit mode, look in taskmanager if your applicaiton has *32 in the end it means its running under 32 bit. A 32 bit application has only 2GB of virtual address space for your application. And an OOM happens when OS could not find sufficient contiguous address to fulfil your application memory request. So to identify the issue i would recommend reading the article http://www.codeproject.com/Articles/176031/Out-of-Memory-Exception-A-simple-string-Split-can-.aspx. If the article above does not solve your problem then you may refer http://blogs.msdn.com/b/tess/archive/2008/02/04/net-debugging-demos-information-and-setup-instructions.aspx.