如何分析由Windows崩溃报告生成WERInternalMetadata.xml文件?文件、报告、Windows、xml

2023-09-03 00:52:48 作者:Acolasia(放纵)

在.NET 4.0的应用程序不断崩溃的用户,但只是为了他,我无法重现bug。他重视由Windows崩溃报告所产生的 WERInternalMetadata.xml 文件。通过打开它,我发现,这是一个 System.IO.FileNotFoundException 崩溃的软件,但是,也有没有函数调用,将抛出那样的异常的功能,所以问题是别的地方或更深。

A .Net 4.0 app keeps crashing for a user, but just for him, I could not reproduce the bug. He attached the WERInternalMetadata.xml file generated by the Windows Crash Reporter. By opening it I found out that it's a System.IO.FileNotFoundException that crashes the software, however, there are no functions called in that function that would throw that kind of exception, so the is problem somewhere else or deeper.

这是文件的最有趣的一部分。它包含(十六进制)的数字,但我无法找出他们的意思。

This is the "most interesting" part of the file. It contains (hexadecimal) numbers, but I couldn't find out what they mean.

<ProblemSignatures>
    <EventType>CLR20r3</EventType>
    <Parameter0>rstvshowtracker.exe</Parameter0>
    <Parameter1>1.0.3842.33258</Parameter1>
    <Parameter2>4c374e79</Parameter2>
    <Parameter3>mscorlib</Parameter3>
    <Parameter4>4.0.0.0</Parameter4>
    <Parameter5>4ba1da6f</Parameter5>
    <Parameter6>1620</Parameter6>
    <Parameter7>14</Parameter7>
    <Parameter8>System.IO.FileNotFoundException</Parameter8>
</ProblemSignatures>

有没有办法找出哪些code会导致异常,或至少找出一些较详细的 FileNotFoundException异常

推荐答案

首先,这里有什么在WER跟踪:

Firstly, here's what's in that WER trace:

<Parameter0>rstvshowtracker.exe</Parameter0> - your exe
<Parameter1>1.0.3842.33258</Parameter1> - version of your exe
<Parameter2>4c374e79</Parameter2> - exe timestamp
<Parameter3>mscorlib</Parameter3> - assembly / module
<Parameter4>4.0.0.0</Parameter4> - assembly version
<Parameter5>4ba1da6f</Parameter5> - assm timestamp
<Parameter6>1620</Parameter6> - methodDef token of faulting method 
<Parameter7>14</Parameter7> - IL offset of faulting instruction
<Parameter8>System.IO.FileNotFoundException</Parameter8> - exception

您可以使用WinDbg和SOS找出什么方法(如1620)。见这里的例子就如何做到这一点: http://blogs.msdn.com/b/oanapl/archive/2009/01/30/windows-error-reporting-wer-and-clr-integration.aspx

You could use WinDBG and SOS to find out what that method is (e.g. 1620). See the example here on how to do it: http://blogs.msdn.com/b/oanapl/archive/2009/01/30/windows-error-reporting-wer-and-clr-integration.aspx

...或者,你可以挂接unhandledException事件在应用程序中,并打印出异常堆栈跟踪到一个日志文件,看看是什么原因造成的问题;例如,

...Alternatively, you could hook up the unhandledException event in your application, and print out the exception stack trace to a log file, to see what caused the issue; e.g.

static void MyHandler(object sender, UnhandledExceptionEventArgs args) 
{
   Exception e = (Exception) args.ExceptionObject;
   // print out the exception stack trace to a log
}

public static void Main() 
{
   AppDomain currentDomain = AppDomain.CurrentDomain;
   currentDomain.UnhandledException += new UnhandledExceptionEventHandler(MyHandler);
}