应用程序崩溃并显示“ .NET运行时内部错误”

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

应用程序：PnrRetrieverService.exe框架版本：v4.0.30319
说明：该进程由于.NET运行时中的内部错误（IP 791F9AAA（79140000），退出代码80131506）而终止。

这在Windows Server 2003 R2 Standard Edition框中。谷歌搜索此错误并没有发现任何相关信息。例如，这不是在VS Studio中发生，而是在生产环境中发生；最终重新启动该服务时，它没有遇到更多问题。

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

退出代码80131506

那真是个令人讨厌的东西，ExecutionEngineException。从.NET 4.0开始，此异常立即终止程序。通用原因是垃圾回收堆的状态损坏。反过来，这又总是由非托管代码引起的。代码中引发此异常的确切位置无济于事，损坏通常在检测到损坏之前就已经发生了。

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

如下面的Microsoft KB条目所述，在x64 .Net 4上并发实现垃圾回收的错误可能导致此问题：

ExecutionEngineException发生在垃圾回收期间

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

小型转储位置通常可以在崩溃条目之后的事件日志的Windows错误报告条目中找到。然后，与WinDbg一起玩！

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

我在.NET运行时遇到了“内部错误”，事实证明这是由我的代码中的错误引起的。不要仅仅因为这是.NET运行时中的一个“内部错误”，就认为代码中没有错误是根本原因。在责怪别人之前，总是总是责备自己的代码。

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

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

经过多年在许多应用程序中解决此问题的努力，看来Microsoft终于接受了它作为.NET 4 CLR中的一个错误，该错误导致了这种情况的发生。http://support.microsoft.com/kb/2640103。

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

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

在WinXP上，与最新版本的.NET 4代码有相同的确切错误。检查了以前的版本-现在它们也崩溃了！好吧，不是我 :)。此处/上方没有建议帮助。

同一问题的更多最新报告（2018-05-09）：退出代码为80131506的应用程序崩溃。

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

根本原因仍然未知（机器尚未更新且使用很少），但这对我而言是成功的！

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

在事件日志中，我看到此错误：

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

和以前的错误：

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

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

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

我不确定它是否可以帮助所有人，但我可以通过运行来解决此问题

devenv.exe /ResetSettings 

...在路上 {Visual_Studio_root}\Common7\Ide

我在事件日志中遇到以下错误，并且VS始终崩溃并重新启动：

Faulting application name: devenv.exe, version: 14.0.25123.0, time stamp: 0x56f22f32
Faulting module name: clr.dll, version: 4.7.2115.0, time stamp: 0x59af88f2
Exception code: 0xc0000005
Fault offset: 0x0015f90e
Faulting process id: 0x3a7c
Faulting application start time: 0x01d353463eaf0c36
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: a232f984-6e80-4f61-9003-e18a035c8f93
Faulting package full name: 
Faulting package-relative application ID: 

就我而言，问题是由于我的web.config中重复的绑定重定向所致。更多信息在这里。

我认为这是因为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>

删除所有重复项即可解决此问题。

就我而言，在登录SAP Business One 9.1应用程序时会发生此错误。在Windows事件中，除了OP报告的事件之外，我还可以找到另一个错误事件：

Nome dell'applicazione che ha generato l'errore: SAP Business One.exe, versione: 9.10.160.0, timestamp: 0x551ad316
Nome del modulo che ha generato l'errore: clr.dll, versione: 4.0.30319.34014, timestamp: 0x52e0b784
Codice eccezione: 0xc0000005
Offset errore 0x00029f55
ID processo che ha generato l'errore: 0x1d7c
Ora di avvio dell'applicazione che ha generato l'errore: 0x01d0e6f4fa626e78
Percorso dell'applicazione che ha generato l'errore: C:\Program Files (x86)\SAP\SAP Business One\SAP Business One.exe
Percorso del modulo che ha generato l'errore: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
ID segnalazione: 3fd8e0e7-52e8-11e5-827f-74d435a9d02c
Nome completo pacchetto che ha generato l'errore: 
ID applicazione relativo al pacchetto che ha generato l'errore: 

该计算机运行Windows 8.1，安装了.NET Framework 4.0，但没有安装4.5版本。从Internet看来，这也可能是.NET 4中的错误，我尝试安装.NET Framework 4.5.2，并解决了该问题。

框架版本：v4.0.30319说明：由于未处理的异常，进程已终止。异常信息：System.Reflection.TargetInvocationException

我遇到了这个错误，应用程序在某些PC上以及在出现上述错误的某些PC上都能正常工作。我卸载了Framework 4.5，然后重新安装解决了我的问题。

欢呼。

这可能是终结器中发生的异常。如果您正在执行〜Class（）{Dispose（false）; }检查要作为非托管资源处理的内容。只需尝试一下..赶上那里，你应该很好。

我们发现了这个问题，因为我们在没有日志的情况下遇到了这种神秘的故障，我们按照通常推荐的方式使用“ void Dispose（bool dispose）”。

通过查看有关finalizer的问题的答案，我们找到了可能的地方，对非托管资源的处置可能会引发异常。

事实证明，在某个地方我们没有适当地处置对象，因此终结器接管了对非托管资源的处置，因此发现发生了异常。

在这种情况下，使用Kafka Rest API从Kafka清除客户端。似乎确实在某个时候引发了异常，然后发生了此问题。

就我而言，问题与“ 在经典asp.net项目中引用.NET标准库 ”和这两个问题有关

https://github.com/dotnet/standard/issues/873

https://github.com/App-vNext/Polly/issues/628

降级到Polly v6就足以解决该问题

我从不知道为什么会发生这种情况。对于我的一个应用程序，它始终具有可复制性，但是在重新启动后就消失了。

我正在使用.net-4.8运行Windows 2004 Build 19582.1001（Insider Preview），如果这是由于诸如硬件内存错误之类的原因，我也不会感到惊讶。另外，我的应用程序确实加载了一些非托管代码并对其进行了初始化，因此我无法证明崩溃不是由该代码引起的。

每5至10分钟，我的应用程序池就会因退出代码而崩溃。我不想破坏您对垃圾收集器的信任，但是以下解决方案对我有用。

我添加了一个GC.GetTotalMemory(true)每分钟调用一次的Job 。

我想由于某种原因，GC不会足够频繁地自动检查内存，以检查我使用的大量一次性对象。