如何分析Windows崩溃报告器生成的WERInternalMetadata.xml文件?
.Net 4.0 应用程序对用户来说不断崩溃,但仅对他而言,我无法重现该错误。他附加了 Windows 崩溃报告器生成的 WERInternalMetadata.xml
文件。通过打开它,我发现这是一个导致软件崩溃的 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 更详细的信息?
A .Net 4.0 app keeps crashing for a user, but just for him, I could not reproduce the bug. He attached the WERInternalMetadata.xml
file generated by the Windows Crash Reporter. By opening it I found out that it's a System.IO.FileNotFoundException
that crashes the software, however, there are no functions called in that function that would throw that kind of exception, so the is problem somewhere else or deeper.
This is the "most interesting" part of the file. It contains (hexadecimal) numbers, but I couldn't find out what they mean.
<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>
Is there a way to find out which code causes the exception, or at least to find out some more details than the FileNotFoundException
?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
首先,这是 WER 跟踪中的内容:
您可以使用 WinDBG 和 SOS 来找出该方法是什么(例如 1620)。请参阅此处的示例了解如何执行此操作:
链接
。 ..或者,您可以在应用程序中连接 unhandledException 事件,并将异常堆栈跟踪打印到日志文件中,以查看导致问题的原因;例如
Firstly, here's what's in that WER trace:
You could use WinDBG and SOS to find out what that method is (e.g. 1620). See the example here on how to do it:
Link
...Alternatively, you could hook up the unhandledException event in your application, and print out the exception stack trace to a log file, to see what caused the issue; e.g.