我使用的是第三方闭源的API，它抛出一个异常，指出“所有的命名管道都很忙”。
我想调试这进一步（而不是仅仅通过步进），所以我其实可以学到什么在幕后发生的事情。
我已使用WinDbg的这一过程的转储。 什么命令，我现在用它来分析这个转储？
谢谢
Answer 1:
你可以开始做如下得到异常的概述：
!analyze -v
现在你可以加载异常背景记录：
.ecxr
而现在...只是看看堆栈，寄存器，线程，...
kb ;will show you the stack trace of the crash.
dv ;local variables
根据你得到的线索，你应该遵循不同的方向。 如果你想快速参考WinDbg的我建议你这个链接 。
我希望你能找到一些这方面的命令和信息有用的。
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
这些命令通常会给你发生了什么事，所以你可以进一步深入研究的概述。 与在那里你没有源库处理，沿发送所产生的日志文件，以供应商的情况下，二进制库的内部版本号应该足以让他们究一个已知的问题，如果有一个。
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-比-A-minute.html
这篇文章是Windows 10，但它包含指向Windows的早期版本的类似信息。
Answer 5:
我假设第三方DLL是本地（否则，只用反射镜）
使用WinDbg的分析，该转储之前，请尝试使用进程监视器（Sysinternals的，免费软件）来监控你的流程的活动。 如果它失败，因为文件系统相关的问题，你可以清楚地看到是什么原因造成的问题，正是它尝试失败之前做。
如果进程监视器是不够的比你可以尝试和调试过程。 但为了看到关于第三方DLL一些有意义的信息，你需要它的PDB的。
设置正确的调试符号后，您可以使用-k命令或它的变化（再次，我假设你在谈论的本机代码）的一个查看调用堆栈。 如果你的进程确实崩溃，因为这个dll比检查您传递给它的功能，以确保问题是不是就在你身边的参数。 我想，再往下调用堆栈，你达到一定的Win32 API - 检查该DLL的函数传递参数，想看看是否有“闻香”。 如果你有DLL的专用符号，你可以检查它的函数的局部变量，以及（DV），它可以给你一些更多的信息。
我希望我给你一个很好的起点。
文章来源: Analysing crash dump in windbg
