c# - How to analyse WERInternalMetadata.xml file generated by Windows Crash Reporter?

Question

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>

Is there a way to find out which code causes the exception, or at least to find out some more details than the FileNotFoundException?

Answer 1

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

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

...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);
}