分析windbg中的崩溃转储

Question

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

我想进一步调试（而不仅仅是单步执行），这样我才能真正了解幕后发生的事情。

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

由于

Answer 1

您可以按照以下步骤来了解异常的概述：

!analyze -v

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

.ecxr

现在......只需看看堆栈，寄存器，线程......

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

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

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

Answer 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

这些命令通常会让您了解所发生的事情，以便您进一步挖掘。在处理没有源代码的库的情况下，将生成的日志文件与二进制库的构建＃一起发送给供应商应该足以让它们跟踪已知问题（如果有的话）。 / p>

Answer 3

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

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

Answer 4

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

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

Answer 5

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

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

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

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

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