Comment analyser le fichier WERInternalMetadata.xml généré par Windows Crash Reporter?

Question

Une application .Net 4.0 continue de se bloquer pour un utilisateur, mais juste pour lui, je n'ai pas pu reproduire le bogue. Il a joint le fichier WERInternalMetadata.xml généré par le Windows Crash Reporter. En l'ouvrant j'ai découvert que c'est un System.IO.FileNotFoundException qui bloque le logiciel, cependant, il n'y a aucune fonction appelée dans cette fonction qui lancerait ce genre d'exception, donc le problème est ailleurs ou plus profond.

Ceci est la partie "la plus intéressante" du fichier. Il contient des nombres (hexadécimaux), mais je n'ai pas pu savoir ce qu'ils signifient.

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

est-il un moyen de savoir quel code fait l'exception, ou du moins pour en savoir un peu plus de détails que le FileNotFoundException?

Answer 1

Tout d'abord, voici ce qui est dans cette trace de REH:

<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 

Vous pouvez utiliser WinDbg et SOS pour savoir ce que cette méthode est (par exemple 1620). Voir l'exemple ici sur la façon de le faire: http://blogs.msdn.com/b/oanapl/archive/2009/01/30/windows-error-reporting-wer-and-clr-integration.aspx

... Sinon, vous pouvez brancher l'événement UnhandledException dans votre application, et imprimer la trace de la pile d'exception dans un fichier journal, pour voir ce qui a causé le problème ; par exemple.

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