Как проанализировать файл WERInternalMetadata.xml, сгенерированный Windows Crash Reporter?
A. Сетевые 4,0 приложения продолжают отказывать для пользователя, но только для него, я не мог воспроизвести ошибку. Он присоединил WERInternalMetadata.xml файл сгенерирован Windows Crash Reporter. Путем открытия его я узнал, что это - a System.IO.FileNotFoundException это разрушает программное обеспечение, однако, нет никаких функций, вызванных в той функции, которая выдала бы такое исключение, таким образом, проблема где-то в другом месте или глубже.
Это - "самая интересная" часть файла. Это содержит (шестнадцатеричные) числа, но я не мог узнать то, что они имеют в виду.
<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?
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);
}