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

【问题标题】：What does it mean when the P9 "bucket" in a .NET crash report contains gibberish instead of the name of the exception that caused the crash?当 .NET 崩溃报告中的 P9“桶”包含乱码而不是导致崩溃的异常的名称时，这意味着什么？
【发布时间】：2012-08-10 10:18:44
【问题描述】：

今天，我们有一位客户在下载并安装了更新版本的产品后，遇到了我们产品的一部分 Windows 服务的问题。

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

在他们安装产品更新并重新启动服务后，它几乎立即崩溃，并在 Windows 事件日志中记录了以下错误信息：

事件类型：错误事件源：.NET 运行时 2.0 错误报告事件类别：无事件编号：5000 日期：2012 年 8 月 13 日时间：上午 11:46:23 用户：不适用计算机：描述： 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 安装是否损坏，或者病毒或其他恶意软件潜伏在他们的服务器上。

那么，如前所述，对于这个相当奇怪的错误报告和 P9“乱码”，或者我应该尝试在 WinDbg 中获取故障转储和调试之外的任何特定故障排除步骤，是否有任何常见的解释？

【问题讨论】：

根据a site I found作为“decode clr20r3”的第二个链接，P9中的异常信息如果太长放不下会被hash。
并且根据这个特定值进行搜索似乎表明它可能与COM Exception有关
哦，最后，模块信息告诉你的只是哪里异常消息的来源。除非您正在执行一些非常不寻常的编程，否则我会认为您的代码会非常频繁地调用 into mscorlib - 那么为什么会出现异常呢？
@Damien_The_Unbeliever：已经很晚了，结果我的 Google fu 显然很糟糕；-)。感谢您及时的回复。至于 mscorlib：好点。我想我只是希望在那里看到一个不同的程序集名称，因为我假设异常发生在服务的一个程序集中并且没有被捕获。
按照这个对相关问题 (stackoverflow.com/a/4053325/17862) 的回答中的建议，异常发生在 mscorlib 中名为 InvokeMember 的方法中，而且该服务确实会进行 COM 互操作调用，因此 COMException 的根本原因实际上不会让我感到惊讶。

标签： .net exception .net-2.0 clr event-log

【解决方案1】：

如果P9 中的异常信息太长而无法放入该字段，则会对其进行哈希处理（我不确定字段的长度是多少，但显然它们是有限的）。

但是，除非您不走运，否则很多人很可能在过去遇到过该哈希码 - 因此您可以根据哈希进行搜索，并且您很可能会找到已经知道的人它实际上是什么类型的异常。在这种情况下，它似乎是COM exception。

最后，所有的模块信息都会告诉你异常的来源。调用代码引发异常的情况并不少见，这将是一个不寻常的 .NET 程序，它没有对 mscorlib 进行多次调用。当我们（现在）知道这是一个 COM 异常时，这尤其不足为奇。

【讨论】：

有趣的是，我无法在运行有问题的客户使用的相同版本的 Windows Server 2003 的 VM 中重现此问题，并且当他们将我们的产品安装在不同的服务器上时也没有出现此问题（运行 Windows 2008 R2)。因此，它似乎是由损坏的 .NET 安装引起的，但尚不清楚这是如何发生的。客户确实说（在后续对话中）他们在一般情况下在那台机器上安装/更新 .NET 时遇到了“麻烦”，但他们无法提供问题的具体细节。
奇怪的是安装在 Windows Server 2003 机器上的我们产品的先前版本可以正常工作。这是一个旧版本，在该版本和客户更新到的版本之间发生了许多重构，但旧版本也进行了 COM 调用，因为这是产品的主要目的。所以，总而言之，这很奇怪。