如何对事件日志中的.NET 2.0错误报告消息进行故障排除?

mkh04yzy  于 2022-11-26  发布在  .NET
关注(0)|答案(8)|浏览(277)

我在开发一个名为EVEMon的开源产品,它是用C#编写的,目标是.NET 2.0平台,我有一个用户,他遇到了一个奇怪的.NET崩溃,我们一直无法解决。

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

应用程序本身崩溃而不显示错误(尽管有错误处理UI),上述消息已从Windows事件日志中复制出来。最终用户已重新安装.NET并更新到最新版本。.PDB文件随程序的每个发行版本一起分发,以帮助调试和测试,有问题的用户具有正确版本的EVEMon的PDB文件的完整补充。
是否有一种特定的、经过实践检验的技术来分析和诊断这种类型的崩溃?如果有,有什么工具和技术可以帮助调试?

特别感谢

我想特别感谢Steffen Opel,并强调他的回答虽然没有直接回答我提出的问题,但解决了我的代码库的更大问题,即全局错误处理缺少一个重要组件。

xqnpmsa8

xqnpmsa81#

这就是我将如何解决最终用户崩溃的问题。
1.下载并安装Windows调试工具,网址为http://www.microsoft.com/whdc/devtools/debugging/default.mspx
1.安装完这些工具后(默认情况下,它们最终会转到C:\Program Files\),请启动命令行窗口。
1.切换到包含adplus的目录(例如“C:\Program Files\Windows调试工具(x86)”)。
1.运行以下命令。这将启动应用程序并连接adplus。
adplus -crash -o C:\debug\ -FullOnFirst -sc C:\path\to\your\app.exe

创建故障转储后

一旦应用程序崩溃,启动WinDbg并加载在C:\debug中创建的.dmp文件。(文件--〉打开崩溃转储)
执行这些命令以查看堆栈跟踪,并希望找到问题所在。
若要载入SOS进行两柴

  • .NET 4.0之前的版本
.loadby sos mscorwks
  • .NET 4.0版本
.loadby sos clr

若要查看堆栈追踪

!clrstack

若要查看更有用的堆栈追踪

!clrstack –p

查看对象内部..也许可以查看导致异常的原因

!do <address>

这是应用程序随机出错的结果,出现IO异常。WinDbg指出了错误的引用路径。

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 <<
zpqajqem

zpqajqem2#

窥视原始程式码( Backbone.js ),表示您的未行程例外状况行程对于Windows Form应用程序而言似乎不完整:
您需要处理非UI线程异常和UI线程异常:

  • 对于前者,您需要通过AppDomain.CurrentDomain.UnhandledException实现CLR未处理的异常处理程序,该处理程序已经就位。
  • 对于后者,您需要通过**Application.ThreadException**实现一个Windows窗体未处理的异常处理程序,但似乎缺少该处理程序;这确实可能产生您所看到的问题。有关实现示例,请参阅Application.ThreadException Event的MSDN文档。

请注意,现在您显式禁止通过Application.SetUnhandledExceptionMode(UnhandledExceptionMode.ThrowException)捕获未处理的Windows窗体异常,您需要将其更改为UnhandledExceptionMode.CatchException,以便为Application.ThreadException启用到处理程序的路由,正如Jehof已经正确建议的那样。

hjzp0vay

hjzp0vay3#

用户使用什么操作系统(Windows XP、Windows Vista等)?
如果Windows Vista尝试禁用“问题报告和解决方案功能”(控制面板--〉问题报告和解决方案--〉更改设置--〉高级设置--〉关闭我的程序,问题报告)
或尝试设置

Application.SetUnhandledExceptionMode( UnhandledExceptionMode.CatchException );

这将始终将异常路由到ThreadException处理程序。

ar5n3qh5

ar5n3qh54#

简而言之:应用程序中存在未处理的异常。
如果您可以存取计算机(透过远程访问等),请尝试安装Visual Studio Express并启动应用程序。您应该会看到一个对话方块,让您有机会以Visual Studio的新执行严修两柴应用程序。
也有可能是因为某些东西阻止了Windows窗体正确初始化。我在论坛上看到过一些帖子,它们认为字体问题可能会导致这种情况--确保用户安装了应用程序所需的字体以及通常的默认字体,如MS SansSerif、Arial、Tahoma、Times等。
如果做不到这一点...试着牺牲一只鸡而不是电脑。每一次都很有魅力!

vvppvyoh

vvppvyoh5#

我们在线程代码中遇到了异常问题。如果您生成了一个新的线程,但忘记处理线程方法中的异常,应用程序只是“停止”-没有错误消息,什么都没有,但只有事件日志中的一个条目。甚至没有UnhandledExceptionHandler被触发。
也许这就是原因?

v9tzhpje

v9tzhpje6#

......如果您能够联系到遭受痛苦的用户,这里有一个

想法:记录预执行阶段

不要创建program.exe的快捷方式,而是创建program.bat的快捷方式,这将

echo "Pre-start" > stage.txt
start program.exe

因此,Program.cs的第一行将为

File.WriteAllLines("stage.txt", "Program execution started.");

AppDomain.UnhandledException的处理程序中,第一行将是

File.WriteAllLines("stage.txt", "Unhandled exception has been caught.");

另外,确保处理程序不分配内存或资源--在程序启动时预分配它们。处理程序只触发对日志的写入。

备注

stage.txt(由用户发送)很可能包含“Pre-start”。当第三方.dll中抛出异常时会发生这种情况-甚至在程序启动之前。
在这种情况下,您将需要一个简单的检查程序,它不会引用您program.exe所引用的程序集,但会引用它们。
附言
stage.txt应该放在%APPDATA%下的某个位置,而不是放在Program Files中。
我找到了an interesting case on Server 2003another nice discussion

kt06eoxx

kt06eoxx7#

您应该通过向用户发送该特定版本的.pdb文件(放在.exe旁边)并让他们重现崩溃来获得更详细的堆栈跟踪。

mkshixfv

mkshixfv8#

您应该在程式码中行程AppDomain.UnhandledException
有一个类似的问题问。见相关的也。

相关问题