Windows 크래시 리포터가 생성 한 WERInternalMetadata.xml 파일을 분석하는 방법은 무엇입니까?

Question

.Net 4.0 앱이 사용자를 위해 계속 충돌하지만 그 사람을 위해 버그를 재현 할 수 없습니다. 그는 Windows 크래시 리포터가 생성 한 WERInternalMetadata.xml 파일을 첨부했습니다. 그것을 열어서 소프트웨어가 충돌하는 것은 System.IO.FileNotFoundException이라는 것을 알았지 만, 그런 종류의 예외를 던질 수있는 함수는 없으므로 다른 곳이나 그보다 더 문제가됩니다.

파일의 "가장 흥미로운 부분"입니다. 여기에는 (16 진수) 숫자가 들어 있지만 그 의미를 알 수는 없습니다.

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

코드는 예외가 발생하거나, 적어도 FileNotFoundException보다는 좀 더 세부 사항을 찾을 수있는 알 수있는 방법이 있습니까?

Answer 1

첫째, 여기에 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 

당신은 그 방법이 무엇인지 알아 WinDBG로하고 SOS를 사용할 수 있습니다 (예를 들어, 1620). 이를 수행하는 방법에 대한 예제는 다음을 참조하십시오. http://blogs.msdn.com/b/oanapl/archive/2009/01/30/windows-error-reporting-wer-and-clr-integration.aspx

... 또는 응용 프로그램에서 unhandledException 이벤트를 연결하고 예외 스택 추적을 로그 파일에 인쇄하여 문제의 원인을 확인할 수 있습니다 ; 예 :

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