应用程序因“.NET 运行时中的内部错误”而崩溃

Application Crashes With "Internal Error In The .NET Runtime"

提问by ALEXintlsos

We have an application written against .NET 4.0 which over the weekend crashed, putting the following message into the event log:

我们有一个针对 .NET 4.0 编写的应用程序，它在周末崩溃了，将以下消息放入事件日志中：

Application: PnrRetrieverService.exe Framework Version: v4.0.30319
Description: The process was terminated due to an internal error in the .NET Runtime at IP 791F9AAA (79140000) with exit code 80131506.

应用程序：PnrRetrieverService.exe 框架版本：v4.0.30319
描述：进程因 IP 791F9AAA (79140000) 的 .NET 运行时内部错误而终止，退出代码为 80131506。

This is on a Windows Server 2003 R2 Standard Edition box. Googling this error hasn't turned up anything pertinent. For example, this isn't occurring in VS Studio, but instead on a production box; when the service was eventually restarted, it experienced no further problems.

这是在 Windows Server 2003 R2 标准版机器上。谷歌搜索这个错误没有发现任何相关的东西。例如，这不会发生在 VS Studio 中，而是发生在生产设备上；当服务最终重新启动时，它没有遇到进一步的问题。

How does one go about diagnosing a bug in the .NET Runtime?

如何诊断 .NET 运行时中的错误？

回答by Hans Passant

with exit code 80131506

退出代码为 80131506

That's a nasty one, ExecutionEngineException. Starting with .NET 4.0, this exception immediately terminates the program. The generic cause is corruption of the state of the garbage collected heap. Which in turn is invariably caused by unmanaged code. The exact location in code at which this exception is raised isn't helpful, the corruption usually occurred well before the damage is detected.

这是一个令人讨厌的，ExecutionEngineException。从 .NET 4.0 开始，此异常会立即终止程序。一般原因是垃圾收集堆的状态损坏。这反过来总是由非托管代码引起的。引发此异常的代码中的确切位置没有帮助，损坏通常发生在检测到损坏之前。

Finding the exact cause for this is going to be difficult. Review any unmanaged code your service might be using. Suspect environmental problems if there is no obvious candidate, misbehaving malware scanners are notorious. If it repeats very poorly then suspect hardware problems like soft RAM errors.

找到造成这种情况的确切原因将很困难。查看您的服务可能正在使用的任何非托管代码。如果没有明显的候选者，怀疑环境问题，行为不端的恶意软件扫描程序是臭名昭著的。如果它重复得非常差，则怀疑硬件问题，如软 RAM 错误。

回答by thinkbeforecoding

A bug in the concurrent implementation of the Garbage Collection on x64 .Net 4can cause this as stated in the following microsoft KB entry:

x64 .Net 4上垃圾收集的并发实现中的错误可能会导致这种情况，如以下 Microsoft KB 条目所述：

ExecutionEngineException occurs during Garbage Collection

ExecutionEngineException 在垃圾收集期间发生

You should first make a deep minidump exploration to be sure that the problem occured during a Garbage collection.

您应该首先进行深入的小型转储探索，以确保问题发生在垃圾收集期间。

The minidump location can usually be found in a Windows Error Reporting entry in the event log following the crash entry. Then, have fun with WinDbg !

小型转储位置通常可以在崩溃条目之后的事件日志中的 Windows 错误报告条目中找到。然后，尽情享受 WinDbg 吧！

The latest documentation on the use of the <gcConcurrent/>configuration element, to disable concurrent or (in .NET 4 and later) background garbage collection, can be found here.

有关使用<gcConcurrent/>配置元素禁用并发或（在 .NET 4 及更高版本中）后台垃圾收集的最新文档，可在此处找到。

回答by jason

I've experienced "internal errors" in the .NET runtime that turned out to be caused by bugs in my code; don't think that just because it was an "internal error" in the .NET runtime that there isn't a bug in your code as the root cause. Always always always blame your own code before you blame someone else's.

我在 .NET 运行时中遇到过“内部错误”，结果证明是由我的代码中的错误引起的；不要认为仅仅因为它是 .NET 运行时中的“内部错误”，您的代码中没有错误是根本原因。在你责怪别人的代码之前，总是总是责怪你自己的代码。

Hopefully you have logging and exception/stack trace information to point you where to start looking, or that you can repeat the state of the system before the crash.

希望您有日志记录和异常/堆栈跟踪信息来指示您从哪里开始查找，或者您可以在崩溃之前重复系统的状态。

回答by johnildergleidisson

For those arriving here from google, I've eventually come across this SO question, and this specific answersolved my problem. I've contacted Microsoft for the hotfix through the live chat on support.microsoft.comand they sent me a link to the hotfix by email.

对于那些从谷歌来到这里的人，我最终遇到了这个 SO question，这个特定的答案解决了我的问题。我已通过support.microsoft.com上的实时聊天与 Microsoft 联系以获取修补程序，他们通过电子邮件向我发送了修补程序的链接。

回答by park896

After years of wrestling with this issue in a number of applications, it appears that Microsoft has finally accepted it as a bug in .NET 4 CLR that causes this to occur. http://support.microsoft.com/kb/2640103.

经过多年在许多应用程序中解决这个问题后，微软似乎终于接受了它作为 .NET 4 CLR 中导致这种情况发生的错误。http://support.microsoft.com/kb/2640103。

I had previously been "fixing" it by forcing the garbage collector to run in server mode (gcServer enabled="true" in app.config) as described in the Microsoft article linked to by Think Before Coding. This in essence forces all threads in the application to pause during the collection removing the possibility of other threads accessing the memory being manipulated by the GC. I am happy to find that my years of searching in vain for a "bug" in my code or other 3rd party unmanaged libraries were only fruitless because the bug lay in Microsoft's code, not mine.

我以前一直通过强制垃圾收集器在服务器模式下运行来“修复”它（app.config 中的 gcServer enabled="true"），如 Think Before Coding 链接的 Microsoft 文章中所述。这实质上强制应用程序中的所有线程在收集期间暂停，从而消除了其他线程访问由 GC 操作的内存的可能性。我很高兴地发现，我多年来徒劳地在我的代码或其他 3rd 方非托管库中搜索“错误”只是徒劳无功，因为错误存在于 Microsoft 的代码中，而不是我的代码中。

回答by Filip Fr?cz

Could be a bug with concurrent GC http://support.microsoft.com/kb/2679415

可能是并发 GC 的错误 http://support.microsoft.com/kb/2679415

回答by Astrogator

Had the same exact error on WinXP box with latest build of my .NET 4 code. Checked previous builds - now they crash too! Ok, so it's not me:). No suggestions here/above helped.

使用我的 .NET 4 代码的最新版本在 WinXP 框上有相同的确切错误。检查以前的版本 - 现在它们也崩溃了！好的，所以不是我:)。这里/上面没有任何建议有帮助。

Much more recent (2018-05-09) report of the same problem: Application Crash with exit code 80131506.

最近 (2018-05-09) 报告了同样的问题：退出代码为 80131506 的应用程序崩溃。

A: We were receiving a similar error, but we believe ours was caused by the Citrix memory optimizer.
The resolution was to force a regeneration of the .Net core libraries on the host(s) where the issue was occurring:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

答：我们收到了类似的错误，但我们相信我们的错误是由 Citrix 内存优化器引起的。
解决方案是强制在发生问题的主机上重新生成 .Net 核心库：
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\ngen.exe update /force

Root cause is still unknown (machine is not being updated and has little use), but that did it for me!

根本原因仍然未知（机器没有更新并且几乎没有用），但这对我来说做到了！

回答by Arthur Smirnov

In my case this exception was occured when disk space was over and .NET can't allocate memory in Windows Virtual Memory.

在我的情况下，当磁盘空间用完并且 .NET 无法在 Windows 虚拟内存中分配内存时，会发生此异常。

In event log I saw this error:

在事件日志中，我看到了这个错误：

Application popup: Windows - Virtual Memory Minimum Too Low : Your system is low on virtual memory. Windows is increasing the size of your virtual memory paging file. During this process, memory requests for some applications may be denied.

应用程序弹出窗口：Windows - 虚拟内存最小值太低：您的系统虚拟内存不足。Windows 正在增加虚拟内存页面文件的大小。在此过程中，可能会拒绝某些应用程序的内存请求。

And previous error:

和之前的错误：

The C: disk is at or near capacity. You may need to delete some files.

C: 磁盘已达到或接近容量。您可能需要删除一些文件。

回答by SiMoStro

In my case the problem was a C++/CLI library in which there was a call to the NtQuerySystemInformation; for some kind of reason sometimes (and under mysterious circumstances), when it was called the CLR heap got corrupted and the application crashed.

就我而言，问题出在 C++/CLI 库中，其中调用了NtQuerySystemInformation；有时（并且在神秘的情况下）出于某种原因，当它被调用时，CLR 堆被损坏并且应用程序崩溃。

I've resolved the problem using a "custom heap" created with HeapCreateand allocating there the buffers used by that function.

我已经使用HeapCreate创建的“自定义堆”解决了这个问题，并在那里分配了该函数使用的缓冲区。

回答by Mark Gibbons

In my case the issue was due to duplicate binding redirects in my web.config. More info here.

在我的情况下，问题是由于我的 web.config 中的重复绑定重定向。更多信息在这里。

I assume it was because of NuGet modifying the binding redirects, but for example it was looking like this:

我认为这是因为 NuGet 修改了绑定重定向，但例如它看起来像这样：

  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Lucene.Net" publicKeyToken="85089178b9ac3181"/>
    <bindingRedirect oldVersion="0.0.0.0-2.9.4.0" newVersion="3.0.3.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed"/>
    <bindingRedirect oldVersion="0.0.0.0-11.0.0.0" newVersion="11.0.0.0"/>
  </dependentAssembly>
  <dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
    <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.0.0.0"/>
  </dependentAssembly>

Removing all the duplicates solved the problem.

删除所有重复项解决了问题。