分析windbg中的崩溃转储答案

【问题标题】：Analysing crash dump in windbg分析windbg中的崩溃转储
【发布时间】：2009-10-30 10:49:23
【问题描述】：

我正在使用第三方闭源 API，它会引发异常，指出“所有命名管道都忙”。

我想进一步调试（而不是单步调试），以便真正了解幕后发生的事情。

我已经使用 WinDbg 转储了这个过程。我现在应该使用什么命令来分析这个转储？

谢谢

【问题讨论】：

它是托管的还是本地的？你能提供更多细节吗？

标签： debugging windbg

【解决方案1】：

您可以开始执行以下操作以了解异常情况：

!analyze -v

现在你可以加载异常上下文记录了：

.ecxr

现在……看看堆栈、寄存器、线程……

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

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

我希望这些命令和信息对您有用。

【讨论】：

【解决方案2】：

在使用 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

这些命令通常可以让您大致了解发生的情况，以便您进一步挖掘。在处理您没有源代码的库的情况下，将生成的日志文件连同二进制库的构建号一起发送给供应商应该足以让他们跟踪到已知问题（如果有）。

【讨论】：

【解决方案3】：

这通常发生在客户端为现有管道调用 CreateFile 并且所有现有管道实例都忙时。此时 CreateFile 返回错误，错误代码为 ERROR_PIPE_BUSY。此时正确的做法是使用超时值调用 WaitNamedPipe 以等待管道实例可用。

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

【讨论】：

【解决方案4】：

我假设第 3 方 dll 是原生的（否则，只需使用 Reflector）

在使用 WinDbg 分析转储之前，请尝试使用 Process-Monitor（SysInternals，免费软件）来监控进程的活动。如果它由于文件系统相关问题而失败，您可以确切地看到导致问题的原因以及在失败之前它尝试做什么。

如果 Process-Monitor 还不够，您可以尝试调试您的流程。但为了查看有关第 3 方 dll 的一些有意义的信息，您需要它的 pdb。

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

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

【讨论】：

【解决方案5】：

这是使用 WinDbg 分析可能有用的崩溃的绝佳资源：http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html

这篇文章适用于 Windows 10，但它包含指向早期 Windows 版本的类似信息的链接。

【讨论】：

链接已损坏。
@UserControl：感谢您指出这一点。我已经更新了答案。