应用程序崩溃“.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: