Wie WERINternalMetadata.xml-Datei zu analysieren, die von Windows Crash Reporter generiert wird?

Question

Eine .Net 4.0 App stürzt für einen Benutzer, aber nur für ihn konnte ich den Fehler nicht reproduzieren. Er fügte die Datei WERInternalMetadata.xml an, die vom Windows Crash Reporter generiert wurde. Durch das Öffnen habe ich herausgefunden, dass es ein System.IO.FileNotFoundException ist, der die Software abstürzt, jedoch gibt es in dieser Funktion keine Funktionen, die diese Art von Ausnahme auslösen würden, so dass das Problem irgendwo anders oder tiefer liegt.

Dies ist der "interessanteste" Teil der Datei. Es enthält (hexadezimale) Zahlen, aber ich konnte nicht herausfinden, was sie bedeuten.

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

Gibt es eine Möglichkeit, um herauszufinden, welcher Code die Ausnahme verursacht oder zumindest einige weitere Details erfahren als die FileNotFoundException?

Answer 1

Zum einen ist hier, was in diesem WER Spur ist:

<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 

Sie WinDBG und SOS nutzen könnten, um herauszufinden, was das Verfahren ist (zum Beispiel 1620). Siehe das Beispiel hier, wie es geht: http://blogs.msdn.com/b/oanapl/archive/2009/01/30/windows-error-reporting-wer-and-clr-integration.aspx

... Alternativ können Sie das UnhandledException Ereignis in Ihrer Anwendung anschließen, und ausdrucken Ausnahme-Stack-Trace in eine Protokolldatei, um zu sehen, was das Problem verursacht ; z.B.

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