Come analizzare il file WERInternalMetadata.xml generato da Windows Crash Reporter?

Question

Un'app .Net 4.0 continua a bloccarsi per un utente, ma solo per lui, non è stato possibile riprodurre il bug. Ha allegato il file WERInternalMetadata.xml generato da Windows Crash Reporter. Aprendolo ho scoperto che si tratta di un errore System.IO.FileNotFoundException, tuttavia, non ci sono funzioni chiamate in quella funzione che genererebbero quel tipo di eccezione, quindi il problema è da qualche altra parte o più profondo.

Questa è la parte "più interessante" del file. Contiene numeri (esadecimali), ma non sono riuscito a scoprire cosa intendessero.

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

C'è un modo per scoprire quale codice causa l'eccezione, o almeno per scoprire qualche dettaglio in più rispetto al FileNotFoundException?

Answer 1

In primo luogo, ecco cosa c'è in quella traccia WER:

<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 

Si potrebbe utilizzare WinDBG e SOS per scoprire cosa che il metodo è (per esempio 1620). Vedere l'esempio qui su come farlo: http://blogs.msdn.com/b/oanapl/archive/2009/01/30/windows-error-reporting-wer-and-clr-integration.aspx

... In alternativa, è possibile collegare l'evento UnhandledException nell'applicazione, e stampare la traccia dello stack eccezione a un file di log, per vedere che cosa ha causato il problema ; per esempio.

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