如何解决.NET 2.0错误报告事件日志中的消息？ [英] How to troubleshoot .NET 2.0 Error Reporting messages in the event log?

问题描述

我使用一个名为 EVEMon 的开源产品编写的C＃针对.NET 2.0平台，我有一个用户遇到了我们无法解决的奇怪的.NET崩溃。

 
事件类型：错误
事件源：.NET Runtime 2.0错误报告
事件类别：无
事件ID：5000 
日期：4/29/2009 
时间：10:58:10 PM 
用户：N / A 
计算机：删除此
说明：
 EventType clr20r3，P1 evemon.exe，P2 1.2.7.1301，P3 49ea37c8，P4 
 system.windows。形式，P5 2.0.0.0，P6 4889dee7，P7 6cd3，P8 18，P9 
 system.argumentexception，P10 NIL。 
 
数据：
 //上述的十六进制表示形式
 

应用程序本身崩溃显示错误（尽管有错误处理UI），但上述消息是从Windows事件日志中复制的。最终用户已重新安装.NET并更新到最新版本。 .PDB文件与程序的每个发布版本一起分发，以帮助调试和测试，具有问题的用户具有用于正确版本的EVEMon的完整PDB文件。

有没有一种特定的，试验和测试的技术来分析和诊断这种类型的崩溃？

特别感谢

我想要使用的工具和技术特别感谢Steffen Opel，并强调他的回答，而不直接回答我问的问题，解决了我的代码库的更大的问题，全局错误处理缺少一个重要的组成部分。

$ b

在下载并安装适用于Windows的调试工具http： //www.microsoft.com/whdc/devtools/debugging/default.mspx

安装工具后，

切换到包含adplus的目录（例如C：\Program Files \Debugging Tools for Windows（x86））。

运行follwing命令。这将启动应用程序并附加adplus。

-crash -o C：\debug\ -FullOnFirst -sc C：\path\to\your\app.exe

创建崩溃转储后

一旦应用程序崩溃，启动WinDbg并加载在C中创建的.dmp文件： \debug。 （文件 - >打开崩溃转储）

执行这些命令查看堆栈跟踪并希望找到问题。

载入SOS进行调试

• Pre .NET 4.0

  .loadby sos mscorwks 
  

• .NET 4.0

  .loadby sos clr 
  

$ b b

查看堆栈跟踪

 ！clrstack 
  

查看更有用的堆栈跟踪

 ！clrstack -p 
  

要戳一个对象，看看是什么引起了异常

 ！do< address> 
  

例如这是来自随机出现IO异常的应用程序的结果。 WinDbg指出被引用的路径不正确。

  0：009> ！do 017f2b7c 
名称：System.String 
 MethodTable：790fd8c4 
 EEClass：790fd824 
大小：124（0x7c）字节
（C：\WINDOWS\assembly \GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll）
字符串：\\server\path\\\
ot_here.txt 
字段：
 MT字段偏移类型VT Attr值名称
 79102290 4000096 4 System.Int32 1实例54 m_arrayLength 
 79102290 4000097 8 System.Int32 1实例53 m_stringLength 
 790ff328 4000098 c System.Char 1实例5c m_firstChar 
 790fd8c4 4000099 10 System.String 0 shared static空
>>域：值00161df8：790d884c< 
 7912dd40 400009a 14 System.Char [] 0 shared static WhitespaceChars 
>>域：值00161df8：014113e8< 
  

I work on an open source product called EVEMon written in C# targeting the .NET 2.0 platform, I have one user who is suffering from a strange .NET crash that we have been unable to resolve.

Event Type: Error
Event Source: .NET Runtime 2.0 Error Reporting
Event Category: None
Event ID: 5000
Date: 4/29/2009
Time: 10:58:10 PM
User: N/A
Computer: removed this
Description:
EventType clr20r3, P1 evemon.exe, P2 1.2.7.1301, P3 49ea37c8, P4
system.windows.forms, P5 2.0.0.0, P6 4889dee7, P7 6cd3, P8 18, P9
system.argumentexception, P10 NIL.

Data:
//hex representation of the above Description

The application itself crashes with out displaying an error (despite having a error handling UI), the above messages was copied out of the Windows Event log. The end user has re-installed .NET and updated to the latest versions. The .PDB files are distributed with every release version of the program to aid in debugging and testing, the user with the problem in question has the full complement of PDB files for the correct version of EVEMon.

Is there a specific, tried and tested technique to analyse and diagnose this type of crash? and if so what tools and technologies are available to aid in debugging?

Special Thanks

I would like to give special thanks to Steffen Opel and highlight that his answer whilst not directly answering the question I was asking, addressed the bigger issue with my code base that the global error handling was missing an important component.

解决方案

This is how I would tackle the problem for a end user with a crash.

1. Download and install Debugging Tools for Windows at http://www.microsoft.com/whdc/devtools/debugging/default.mspx

2. Once the tools are installed (they end up going to C:\Program Files\ by default) start a command line window.

3. Change to the directory which contains adplus (e.g "C:\Program Files\Debugging Tools for Windows (x86)").

4. Run the follwing command. This will start the application and attach adplus.

adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe

After the crash dump is created

Once the application crashes start WinDbg and load the .dmp file that is created in C:\debug. (File --> Open Crash Dump)

Execute these commands to see the stack trace and hopefully find the problem.

To load SOS for debugging

• Pre .NET 4.0

.loadby sos mscorwks

• .NET 4.0

.loadby sos clr

To see the stack trace

!clrstack

To see a more useful stack trace

!clrstack –p

To poke inside an object..perhaps see what caused the exception

!do <address>

e.g This is the result from a application that faulted randomly with an IO exception. WinDbg pointed out the path that was being referenced which was incorrect.

0:009> !do 017f2b7c    
Name: System.String    
MethodTable: 790fd8c4    
EEClass: 790fd824    
Size: 124(0x7c) bytes    
 (C:\WINDOWS\assembly\GAC_32\mscorlib\2.0.0.0__b77a5c561934e089\mscorlib.dll)    
String: \\server\path\not_here.txt
Fields:    
      MT    Field   Offset                 Type VT     Attr    Value Name    
79102290  4000096        4         System.Int32  1 instance       54 m_arrayLength    
79102290  4000097        8         System.Int32  1 instance       53 m_stringLength    
790ff328  4000098        c          System.Char  1 instance       5c m_firstChar    
790fd8c4  4000099       10        System.String  0   shared   static Empty    
    >> Domain:Value  00161df8:790d884c <<    
7912dd40  400009a       14        System.Char[]  0   shared   static WhitespaceChars    
    >> Domain:Value  00161df8:014113e8 <<

这篇关于如何解决.NET 2.0错误报告事件日志中的消息？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！