当.NET崩溃报告中的P9"桶"包含乱码而不是导致崩溃的异常名称时,这意味着什么？

Question

今天我们遇到一个客户遇到了Windows服务的问题,这些服务是他们下载并安装了更新版本的产品之后的一部分.

他们在Windows Server 2003 R2(Service Pack 2)计算机上运行该服务,该计算机上安装了.NET 2.0(这是该服务器上最新版本的.NET Framework).

安装产品更新并重新启动服务后,它几乎立即崩溃,并将以下错误信息记录到Windows事件日志中:

Event Type: Error
Event Source:   .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID:   5000
Date:       8/13/2012
Time:       11:46:23 AM
User:       N/A
Computer:   
Description:
EventType clr20r3, P1 our-service-name-redacted.exe, P2 2.6.31.0, P3 4fcd090b, P4 mscorlib, P5 2.0.0.0, P6 4889dc80, P7 e38, P8 1e8, P9 pszqoadhx1u5zahbhohghldgiy4qixhx, P10 NIL.

现在,其他一些客户正在运行相同版本的Windows服务而没有任何问题(在不同版本的Windows上),我在运行Windows Server 2003 R2(Service Pack 2)的虚拟机上测试了该服务,但没有遇到此问题问题,但对于这个单一客户而言,它始终如一.

所以,这不是"我的代码出了什么问题？" 问题:我对这个错误信息有两点感兴趣,我觉得很奇怪:

• 故障模块(P4)是mscorlib
• P9,通常应该命名为我理解的事情发生的异常,包含看起来像垃圾数据(或者某种混淆信息？)

对此有一般性的解释吗？我尝试使用谷歌搜索,但没有太多的运气,因为很难搜索"P9垃圾"和类似的东西,并获得任何有用的东西.特别是,我真的很好奇P9的"乱码"值是什么意思.例如,这可能暗示他们的.NET安装已损坏,或者这种"胡言乱语"实际意味着什么？

此外,我有点惊讶故障模块是mscorlib而不是我们自己的程序集之一,这让我再次想知道客户的.NET安装是否已损坏,或者是否有病毒或其他恶意软件潜伏在他们的服务器上.

因此,如上所述,对于这个相当奇怪的错误报告和P​​9"乱码",或者我应该尝试除了尝试在WinDbg中进行故障转储和调试之外的任何特定故障排除步骤,是否有任何常见的解释？

Answer 1

如果异常信息P9太长而无法放入字段中,那么异常信息将被散列(我不确定字段的长度是多少,但显然它们是有限的).

但是,除非你运气不好,这是很有可能的哈希码将已被大量的人过去遇到的-这样你就可以基于散列做搜索,你可能会发现人谁已经知道是什么类型的它实际上是例外.在这种情况下,它似乎是一个COM异常.

最后,所有模块信息都告诉您发生异常的位置.你调用的代码抛出异常并不常见,而且这是一个不常见的.NET程序,它没有对mscorlib进行过多调用.当我们(现在)知道它是COM异常时,这一点尤其不足为奇.