3

今天，我们的一位客户在下载并安装了更新版本的产品后，遇到了作为我们产品一部分的 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 中进行故障转储和调试之外的任何特定故障排除步骤，是否有任何常见的解释？

4

1 回答 1

7

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

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

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

于 2012-08-16T07:59:45.703 回答