分析.net 4.0的gflags.exe创建的故障转储，但没有足够的信息
用 c# 4.0 编写的 Windows 服务，设置 gflags.exe(Global Flags) 在进程崩溃时保存转储。
但是当我在 Windbg 中打开故障转储时，我得到了 0:00> 。我不擅长windbg，我记得Tess的博客说当打开故障转储时你应该看到发生异常的线程id，但我看到的是0:00>...并且！pe没有有用的结果。
使用 !dumpheap -stat，我只能看到很少的对象，那么我如何分析这个转储呢？ 非常感谢您的帮助。
a windows service written in c# 4.0, setting gflags.exe(Global Flags) to save the dump when process crashing.
But when I open the crash dump in windbg, I got the 0:00> . I am not good at windbg, and I remembered Tess's blog said when opening a crash dump you should see the threads id which the exception occurs, but what I see is 0:00>... and !pe has no useful result.
using !dumpheap -stat, I could only see few objects, so how can I analysis this dump?
thanks a lot for any help.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您使用 !dumpheap -stat 看到很少有对象，则该转储可能生成得太晚，或者生成的时间错误。
您可以尝试使用 Debug Diag 或 ADPlus 重新捕获转储（当然，在此之前您需要重置 GFlags 中的更改）。
http ://blogs.msdn.com/b/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx
If you see few objects using !dumpheap -stat, then it is likely that this dump was generated too late, or at a wrong time.
You may try to use Debug Diag or ADPlus to recapture the dump (of course you need to reset the changes in GFlags before doing that).
http://blogs.msdn.com/b/lexli/archive/2009/08/23/when-the-application-program-crashes-on-windows.aspx
~*e !pe 是否输出您感兴趣的异常？
漫长的道路是：
Does ~*e !pe output an exception of your interest?
The long way is: