在windbg中分析崩溃转储

我正在使用第三方封闭源代码API，它引发一个异常，指出“所有命名管道都很忙”。在windbg中分析崩溃转储

我想进一步调试（而不是仅仅通过），所以我实际上可以了解封面下发生了什么。

我已使用WinDbg转储了此过程。我现在应该使用哪些命令来分析此转储？

感谢

2009-10-30 csharpdev

它是托管还是本机？你能抛出更多的细节吗？ – Naveen 2009-10-30 13:58:27

这当客户端调用的CreateFile对现有管道和所有现有的管道实例都忙普遍发生。此时CreateFile返回一个错误，错误代码是ERROR_PIPE_BUSY。此时正确的方法是使用超时值调用WaitNamedPipe以等待管道实例变为可用。

当多个客户端尝试同时连接到命名管道时，通常会发生此问题。

来源

2009-10-31 18:23:21 steve

我认为第三方DLL是本地（否则，只用反射镜）

使用的WinDbg分析转储之前，请尝试使用进程监视器（Sysinternals的，免费软件）来监控你的流程的活动。如果由于文件系统相关问题而导致失败，您可以准确查看是什么导致了问题，以及在发生故障前究竟发生了什么。

如果Process-Monitor不够，那么您可以尝试并调试您的过程。但为了查看关于第三方DLL的一些有意义的信息，您将需要它是pdb的。

设置正确的调试符号后，您可以使用k命令或其中一个变体（我假设您正在谈论本机代码）查看调用堆栈。如果你的进程确实因为这个DLL而崩溃，而不是检查你传递给它的函数的参数，以确保问题不在你身边。我猜想进一步调用堆栈，你会到达一些Win32 API--检查dll函数传递的参数，试图看看是否有“异味”。如果你有dll的私有符号，你可以检查它的函数的局部变量（dv），它可以给你更多的信息。

我希望我给你一个很好的起点。

来源

2009-11-06 18:35:39

这对于使用WinDbg的分析死机，可能是一些使用的一个很好的资源：http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

文章是Windows 10，但它包含指向Windows的早期版本的类似信息。

来源

2009-11-06 18:43:39 boot13

链接已损坏。 – UserControl 2017-03-29 17:08:52

@UserControl：谢谢指出。我已经更新了答案。 – boot13 2017-04-01 02:37:56

在使用Windbg进行事后调试时，在决定深入挖掘之前运行一些常规诊断命令会很有用。这些应该是你的第一个步骤：

.logopen <filename> (See also .logappend) 
.lastevent    See why the process halted and on what thread 
u      List disassembly near $eip on offending thread 
~      Status of all threads 
Kb      List callstack, including parameters 
.logclose

这些命令通常会给你发生了什么事，所以你可以进一步深入研究的概述。在处理没有源代码的库的情况下，将生成的日志文件与二进制库的构建号一起发送给供应商应该足以让它们追踪到已知问题（如果有的话）。

来源

2009-12-03 17:37:24

你可以开始做如下得到异常的概述：

!analyze -v

现在你可以加载异常背景记录：

.ecxr

而现在......只是来看看在堆栈，寄存器，线程，...

kb  ;will show you the stack trace of the crash. 
dv  ;local variables

根据你得到的线索，你应该遵循一个dif不寻常的方向。如果你想快速参考WinDbg，我建议你this link。

我希望你找到一些这些命令和信息有用。

来源

2009-12-04 09:57:29

在windbg中分析崩溃转储

回答

相关问题