应用程序崩溃“.NET运行时内部错误”
我们有一个针对.NET 4.0的应用程序，这个应用程序在周末崩溃，把下面的消息放到事件日志中：
应用程序：PnrRetrieverService.exe框架版本：v4.0.30319
说明：由于.NET运行时的IP 791F9AAA（79140000）退出代码为80131506的内部错误，进程已终止。
这是在Windows Server 2003 R2标准版盒子上。 谷歌search这个错误没有发现任何相关的。 例如，这在VS Studio中不会发生，而是在生产箱中发生; 当服务最终重新启动时，不会再遇到任何问题。
如何诊断.NET运行时错误？
退出代码80131506
这是一个令人讨厌的，ExecutionEngineException。 从.NET 4.0开始，这个exception立即终止程序。 通用的原因是垃圾收集堆状态的腐败。 而这又总是由非托pipe代码引起的。 代码中引发此exception的确切位置是无用的，通常在检测到损坏之前发生损坏。
find确切的原因将是困难的。 查看您的服务可能使用的任何非托pipe代码。 怀疑环境问题，如果没有明显的候选人，行为恶意软件扫描仪臭名昭着。 如果重复性很差，那么怀疑软RAM问题等硬件问题。
垃圾收集在x64 .Net 4的并发实现中的一个错误可能会导致此问题，如下面的Microsoft知识库条目中所述：
垃圾回收期间发生ExecutionEngineException
您应该首先进行深入的小型转储探索，以确保垃圾收集期间发生问题。
通常可以在崩溃条目之后的事件日志中的Windows错误报告条目中find小型转储位置。 然后，与WinDbg玩得开心！
有关使用<gcConcurrent/>configuration元素来禁用并发或（在.NET 4及更高版本中）后台垃圾回收的最新文档可以在这里find。
我在.NET运行时遇到过“内部错误”，这是我的代码中的错误导致的; 不要以为这是.NET运行时的一个“内部错误”，因为在你的代码中没有错误作为根本原因。 总是总是责备自己的代码，然后才怪别人的。
希望你有logging和exception/堆栈跟踪信息来指示你从哪里开始寻找，或者你可以在崩溃之前重复系统的状态。
对于那些从谷歌到这里，我终于遇到这个问题 ， 这个具体的答案解决了我的问题。 我已经通过support.microsoft.com上的实时聊天与Microsoft联系了此修补程序，并且他们通过电子邮件向我发送了修补程序的链接。
可能是并发GC的一个错误http://support.microsoft.com/kb/2679415
经过多年的应用程序的这个问题的摔跤，看来微软终于接受了它作为.NET 4 CLR中的一个错误，导致这种情况发生。 http://support.microsoft.com/kb/2640103 。
我以前一直在通过强制垃圾收集器以服务器模式（app.config中的gcServer enabled =“true”）运行来修复它，如Think编码链接到的Microsoft文章中所述。 这实质上是强制应用程序中的所有线程在收集过程中暂停，以避免其他线程访问由GC操作的内存。 我很高兴地发现，多年来我在代码或其他第三方非托pipe库中徒劳地search“bug”只是徒劳无功，因为这个错误在微软的代码中，而不是我的。
在我的情况下，这个exception是当磁盘空间已经结束，.NET不能在Windows虚拟内存中分配内存。
在事件日志中，我看到了这个错误：
应用程序popup窗口：Windows – 虚拟内存最小太低：您的系统虚拟内存不足。 Windows正在增加虚拟内存页面文件的大小。 在此过程中，某些应用程序的内存请求可能会被拒绝。
和以前的错误：
C：磁盘处于或接近容量。 您可能需要删除一些文件。
Framework版本：v4.0.30319说明：由于未处理的exception，进程已终止。 exception信息：System.Reflection.TargetInvocationException
我遇到了这个错误，应用程序在一些电脑和一些电脑上出现上述错误时工作正常。 我卸载框架4.5，并重新安装这解决了我的问题。
欢呼。
在我的情况下，问题是一个C ++ / CLI库，其中有一个调用NtQuerySystemInformation ; 出于某种原因有时（在神秘的情况下 ），当它被称为CLR堆被损坏，应用程序崩溃。
我已经使用由HeapCreate创build的“自定义堆”解决了问题，并在那里分配了该函数使用的缓冲区。
在我的情况下，在loginSAP 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中的一个bug，我尝试安装.NET Framework 4.5.2，并解决了这个问题。
这可能是终结者中发生的exception。 如果你正在做〜Class的模式（）{Dispose（false）; }检查你作为一个未被pipe理的资源处理什么。 只要在那里尝试一下，你应该没问题。
我们发现这个问题，因为我们有这个神秘的失败，没有日志我们做了使用“void Dispose（bool disposing）”的通常推荐模式。
查看关于终结器的这个问题的答案，我们发现了一个可能的地方，非托pipe资源的处置可能会引发exception。
事实certificate，我们没有妥善处理这个对象，因此终结者接pipe了非托pipe资源，因此看到了一个例外。
在这种情况下，使用Kafka Rest API从Kafka清理客户端。 似乎它在某个时候抛出exception，然后发生了这个问题。
我不知道它可以帮助每个人，但我可以通过运行来解决这个问题
devenv.exe /ResetSettings
…path{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:
