使用Windbg分析崩溃转储文件

10

我正在使用一个第三方的闭源API,它抛出异常并声明“所有命名管道都在忙碌中”。

我想进一步调试这个问题(而不仅是简单地步进),以便我可以真正了解底层发生了什么。

我已经使用WinDbg对此进程进行了dump。现在应该使用什么命令来分析这个dump呢?

谢谢


它是托管的还是本地的?你能再提供一些细节吗? - Naveen
5个回答

20
您可以按照以下步骤来获得异常的概述:
!analyze -v

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

.ecxr

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

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

根据您获得的线索,您应该选择不同的方向。如果您想快速了解WinDbg,我建议您访问此链接

希望您会觉得这些命令和信息有用。


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

这些命令通常会为您提供事件的概述,以便您可以进一步了解。在处理没有源代码的库时,将生成的日志文件与二进制库的版本号一起发送给供应商,如果存在已知问题,则应足以使他们追踪到该问题。


2

当客户端调用CreateFile来打开一个已存在的管道,而所有现有的管道实例都在繁忙状态时,通常会出现这种情况。此时CreateFile返回一个错误,错误代码为ERROR_PIPE_BUSY。此时正确的做法是使用超时值调用WaitNamedPipe等待管道实例可用。

一般情况下,当多个客户端尝试同时连接到命名管道时,就会出现这个问题。


0

我假设第三方dll是本地的(否则使用Reflector即可)

在使用WinDbg分析转储文件之前,尝试使用Process-Monitor(SysInternals,免费软件)来监视进程的活动。如果由于文件系统相关问题而失败,您可以准确地查看导致问题的原因以及出现故障前它试图执行的操作。

如果Process-Monitor还不够强大,则可以尝试调试进程。但是为了查看有关第三方dll的一些有意义的信息,您需要它的pdb文件。

设置正确的调试符号后,可以使用k命令或其变体之一查看调用堆栈(再次声明,我假设您正在谈论本地代码)。如果您的进程确实因为此dll而崩溃,请检查传递给其函数的参数,以确保问题不在您这边。我猜测,在调用堆栈的深处,您会到达某个Win32 API-检查dll函数传递的参数,尝试查看是否存在疑点。如果您有该dll的私有符号,则还可以检查其函数的局部变量(dv),这可以为您提供更多信息。

希望我为您提供了一个很好的起点。


0

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

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接