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

Question

AP .NET 4.0 App continua a schiantarsi per un utente, ma solo per lui, non potrei riprodurre il bug.Allegata il file WERInternalMetadata.xml generato dal reporter del crash di Windows.Aprendolo ho scoperto che è un System.IO.FileNotFoundException che schianta il software, tuttavia, non ci sono funzioni chiamate in quella funzione che avrebbero lanciato quel tipo di eccezione, quindi il problema è da qualche altra parte o più profondo.

Questa è la parte "più interessante" del file.Contiene numeri (esadecimale), ma non riuscivo a scoprire cosa significano.

<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 provoca l'eccezione, o almeno di scoprire alcuni dettagli rispetto al FileNotFoundException?

Answer 1

Prima cosa, 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

.

È possibile utilizzare Windbg e SOS per scoprire cosa è il metodo (ad esempio 1620).Guarda l'esempio qui su come farlo: http://blogs.mssdn.com/b/oanapl/archive/2009/01/30/windows-errorror-reporting-wer-and-clr-integrazione.aspx

... In alternativa, è possibile collegarsi l'evento UnhandledException nell'applicazione e stampare la traccia della pila di eccezione in un file di registro, per vedere cosa ha causato il problema;ad 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);
}

.