我正在使用一个第三方的闭源API,它抛出异常并声明“所有命名管道都在忙碌中”。
我想进一步调试这个问题(而不仅是简单地步进),以便我可以真正了解底层发生了什么。
我已经使用WinDbg对此进程进行了dump。现在应该使用什么命令来分析这个dump呢?
谢谢
!analyze -v
现在,您可以加载异常上下文记录:
.ecxr
现在...只需看看堆栈、寄存器、线程等...
kb ;will show you the stack trace of the crash.
dv ;local variables
根据您获得的线索,您应该选择不同的方向。如果您想快速了解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
这些命令通常会为您提供事件的概述,以便您可以进一步了解。在处理没有源代码的库时,将生成的日志文件与二进制库的版本号一起发送给供应商,如果存在已知问题,则应足以使他们追踪到该问题。
当客户端调用CreateFile来打开一个已存在的管道,而所有现有的管道实例都在繁忙状态时,通常会出现这种情况。此时CreateFile返回一个错误,错误代码为ERROR_PIPE_BUSY。此时正确的做法是使用超时值调用WaitNamedPipe等待管道实例可用。
一般情况下,当多个客户端尝试同时连接到命名管道时,就会出现这个问题。
我假设第三方dll是本地的(否则使用Reflector即可)
在使用WinDbg分析转储文件之前,尝试使用Process-Monitor(SysInternals,免费软件)来监视进程的活动。如果由于文件系统相关问题而失败,您可以准确地查看导致问题的原因以及出现故障前它试图执行的操作。
如果Process-Monitor还不够强大,则可以尝试调试进程。但是为了查看有关第三方dll的一些有意义的信息,您需要它的pdb文件。
设置正确的调试符号后,可以使用k命令或其变体之一查看调用堆栈(再次声明,我假设您正在谈论本地代码)。如果您的进程确实因为此dll而崩溃,请检查传递给其函数的参数,以确保问题不在您这边。我猜测,在调用堆栈的深处,您会到达某个Win32 API-检查dll函数传递的参数,尝试查看是否存在疑点。如果您有该dll的私有符号,则还可以检查其函数的局部变量(dv),这可以为您提供更多信息。
希望我为您提供了一个很好的起点。
这是一个使用WinDbg分析崩溃的绝佳资源,可能会对您有所帮助:http://www.networkworld.com/article/3100370/windows/how-to-solve-windows-10-crashes-in-less-than-a-minute.html
该文章适用于Windows 10,但其中包含了早期版本Windows类似信息的链接。