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

Question

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

ALE*_*sos 106 .net runtime-error executionengineexception

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

应用程序:PnrRetrieverService.exe Framework版本:v4.0.30319
描述:由于.NET运行时在IP 791F9AAA(79140000)处出现内部错误而导致进程终止,退出代码为80131506.

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

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

Answer 1

Han*_*ant 117

退出代码为80131506

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

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

我看着它. (55认同)
使用此Err.exe工具http://www.microsoft.com/en-au/download/details.aspx?id=985找出像80131506这样的十六进制错误代码的含义以及包含它们的头文件. (6认同)
它们列在SDK头文件CorError.h中 (4认同)
我有[SQL CE 3.5的问题](http://www.robertdowney.com/post/2011/04/13/Trials-and-Tribulations-with-SQL-Server-Compact-Edition.aspx)破坏了堆,导致ntdll.dll和.NET运行时错误中的异常. (3认同)
您怎么知道它们在CorError.h中列出了？ (2认同)
@HansPassant我认为提出的问题是“世界上存在的所有文件中，您怎么知道CorError.h是值得查看的文件”？ (2认同)
我不太理解这样的评论，它们都值得一看，而且SDK只是“世界上存在的所有文件”的很小一部分。就像访问您当地的图书馆一样，您为什么不故意不看书呢？也许封面没有吸引力，但是很快就可以看到他们命名文件的方式背后的模式。 (2认同)

Answer 2

thi*_*ing 39

在x64 .Net 4上并发执行垃圾收集的错误可能导致如下面的Microsoft KB条目中所述:

垃圾收集期间发生ExecutionEngineException

您应首先进行深入的minidump探索,以确保在垃圾收集期间出现问题.

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

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

你是一个救生员，这对我们来说是个问题。另外，您还可以在 Visual Studio 中打开小型转储文件，根据需要设置符号路径，然后进行调试。这告诉我们错误发生在 clr.dll!WKS::gc_heap::mark_object_simple()。我确信 WinDbg 非常强大，但是如果您只是在验证错误的来源，使用 VS 可以告诉您足够的信息。 (2认同)
对于处于相同情况的其他人，配置 Windows 错误报告以在崩溃时执行完整的堆转储可能很有用：https://msdn.microsoft.com/en-us/library/windows/desktop/bb787181(v=vs .85).aspx (2认同)

Answer 3

jas*_*son 10

我在.NET运行时经历过"内部错误",结果是由我的代码中的错误引起的; 不要以为仅仅因为它是.NET运行时中的"内部错误"而导致代码中没有错误作为根本原因.在责怪别人之前,总是总是责怪你自己的代码.

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

Answer 4

joh*_*son 7

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

Answer 5

par*_*896 5

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

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

Answer 6

Ast*_*tor 5

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

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

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

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

归档时间：	14 年，9 月前
查看次数：	114602 次
最近记录：	6 年，4 月前