问题描述
我在一个名为 EVEMon 的开源产品上工作，该产品用 C# 编写，面向 .NET 2.0 平台，我有一位用户遇到了我们无法解决的奇怪的 .NET 崩溃问题.
<上一页>事件类型:错误事件源:.NET 运行时 2.0 错误报告事件类别:无事件编号:5000日期:2009 年 4 月 29 日时间:晚上 10:58:10用户:不适用电脑:删除了这个描述:事件类型 clr20r3、P1 evemon.exe、P2 1.2.7.1301、P3 49ea37c8、P4system.windows.forms，P5 2.0.0.0，P6 4889dee7，P7 6cd3，P8 18，P9system.argumentexception，P10 无.数据://以上描述的十六进制表示应用程序本身崩溃而没有显示错误(尽管有错误处理 UI)，上述消息是从 Windows 事件日志中复制出来的.最终用户已重新安装 .NET 并更新到最新版本..PDB 文件随程序的每个发行版本一起分发，以帮助调试和测试，有问题的用户拥有正确版本的 EVEMon 的完整 PDB 文件.
是否有专门的、经过验证的技术来分析和诊断这种类型的崩溃?如果是，有哪些工具和技术可用于帮助调试?
特别感谢
我要特别感谢 Steffen Opel 并强调 他的回答虽然没有直接回答我提出的问题，但解决了我的代码库中更大的问题，即全局错误处理缺少一个重要组件.
这就是我为最终用户解决崩溃问题的方法.
在 http://www 下载并安装适用于 Windows 的调试工具.microsoft.com/whdc/devtools/debugging/default.mspx
安装工具后(默认情况下它们最终会转到 C:Program Files)启动命令行窗口.
切换到包含 adplus 的目录(例如C:Program FilesDebugging Tools for Windows (x86)").
运行以下命令.这将启动应用程序并附加 adplus.
<块引用>
adplus -crash -o C:debug -FullOnFirst -sc C:path oyourapp.exe
创建故障转储后
一旦应用程序崩溃启动 WinDbg 并加载在 C:debug 中创建的 .dmp 文件.(文件 --> 打开故障转储)
执行这些命令以查看堆栈跟踪并希望找到问题.
加载 SOS 进行调试
- .NET 4.0 之前
.loadby sos mscorwks- .NET 4.0
.loadby sos clr查看堆栈跟踪
!clrstack查看更有用的堆栈跟踪
!clrstack –p戳入一个对象..也许看看是什么导致了异常
!do <地址>例如，这是由于应用程序随机出现 IO 异常而导致的结果.WinDbg 指出被引用的路径不正确.
0:009>!do 017f2b7c名称:System.String方法表:790fd8c4EE类:790fd824大小:124(0x7c)字节(C:WINDOWSassemblyGAC_32mscorlib2.0.0.0__b77a5c561934e089mscorlib.dll)字符串:\serverpath
ot_here.txt领域:MT 字段偏移类型 VT Attr 值名称79102290 4000096 4 System.Int32 1 实例 54 m_arrayLength79102290 4000097 8 System.Int32 1 个实例 53 m_stringLength790ff328 4000098 c System.Char 1 实例 5c m_firstChar790fd8c4 4000099 10 System.String 0 共享静态空>>域:值 00161df8:790d884c <<7912dd40 400009a 14 System.Char[] 0 共享静态 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.
Download and install Debugging Tools for Windows at http://www.microsoft.com/whdc/devtools/debugging/default.mspx
Once the tools are installed (they end up going to C:Program Files by default) start a command line window.
Change to the directory which contains adplus (e.g "C:Program FilesDebugging Tools for Windows (x86)").
Run the follwing command. This will start the application and attach adplus.
adplus -crash -o C:debug -FullOnFirst -sc C:path oyourapp.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:WINDOWSassemblyGAC_32mscorlib2.0.0.0__b77a5c561934e089mscorlib.dll)
String: \serverpath
ot_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 错误报告消息进行故障排除?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持跟版网！