Question

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

应用程序：PnrRetrieverService.exe Framework版本：v4.0.30319
描述：由于内部错误导致进程终止运行时的IP 791F9AAA（79140000），退出代码为80131506。

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

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

Answer 1

退出代码为80131506

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

找到确切的原因很难。查看您的服务可能正在使用的任何非托管代码。如果没有明显的候选人，那些行为不端的恶意软件扫描程序是臭名昭着的，那就是怀疑环境问题。如果它重复得非常差，那么就会出现软RAM错误等可疑硬件问题。

Answer 2

x64 .Net 4 上垃圾收集的并发实现中的错误可能会导致以下微软KB条目中所述：

ExecutionEngineException occurs during Garbage Collection

您应首先进行深入的minidump探索，以确保在垃圾收集过程中出现问题。

minidump位置通常可以在崩溃条目后的事件日志中的Windows错误报告条目中找到。然后，享受WinDbg的乐趣！

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

Answer 3

我在.NET运行时经历过“内部错误”，原因是我的代码中存在错误;不要以为仅仅因为它是.NET运行时中的“内部错误”而导致代码中没有错误作为根本原因。在责怪别人之前，总是总是责备自己的代码。

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

Answer 4

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

Answer 5

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

Answer 6

在多个应用程序中经过多年与此问题的斗争之后，似乎微软最终将其视为.NET 4 CLR中导致此问题发生的错误。 http://support.microsoft.com/kb/2640103

我以前通过强制垃圾收集器在服务器模式下运行来“修复”它（在app.config中gcServer enabled =“true”），如编辑前的微软文章所述。这实质上强制应用程序中的所有线程在集合期间暂停，从而消除其他线程访问由GC操纵的内存的可能性。我很高兴地发现，我在代码或其他第三方非托管库中找到“bug”的徒劳无功只是徒劳无功，因为这个bug存在于微软的代码中，而不是我的代码。

Answer 7

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

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

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

以前的错误：

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

Answer 8

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

关于同一问题的最新报告（2018-05-09）：Application Crash with exit code 80131506。

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

根本原因仍然未知（机器尚未更新且使用很少），但那是对我有用的！

Answer 9

我不确定它对每个人都有帮助，但我可以通过运行

来解决这个问题

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:

Answer 10

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

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

Answer 11

在我的情况下，问题与“ 在经典的asp.net项目中引用.NET标准库”和这两个问题

有关

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

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

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

Answer 12

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

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

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

Answer 13

这可能是终结器中发生的异常。如果你正在进行~Class（）的模式{Dispose（false）;检查你作为一个未受管理的资源处置什么。只需在那里试一试，你应该没问题。

我们发现了这个问题，因为我们遇到了这个没有日志的神秘故障我们采用了通常推荐的使用＆＃34; void Dispose（bool disposing）＆＃34;的模式。

查看关于终结器的这个问题的答案，我们发现了一个可能的地方，非托管资源的处置可能会引发异常。

事实证明，我们没有正确处理对象，因此终结器接管了非托管资源，因此发现了异常。

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

Answer 14

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

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

欢呼。

Answer 15

在我的情况下，登录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版本。从互联网上看，它可能也是.NET 4中的一个错误，我尝试了安装.NET Framework 4.5.2 ，我解决了这个问题。

Answer 16

在我的情况下，问题是一个C ++ / CLI库，其中有一个NtQuerySystemInformation的调用;出于某种原因，有时候（以及神秘的情况下），当它被调用时，CLR堆被破坏并且应用程序崩溃。

我使用＆＃34;自定义堆来解决问题＆＃34;使用HeapCreate创建并在那里分配该函数使用的缓冲区。

Answer 17

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

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

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

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

17 个答案: