tags:

views:

50

answers:

1

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?

+1  A: 

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);
}
Chris Brook
Thank you very much! I was able to trace down the bogus code. On the other hand, I am catching UnhandledException event, but if an exception is thrown on a new thread, the app freezes and no UnhandledException gets fired. In the new version I fixed this by using Tasks instead of Thread, because Tasks lets me catch exceptions thrown on another thread.
RoliSoft