我正在使用第三方闭源 API，它会抛出一个异常，指出“所有命名管道都忙”。
我想进一步调试（而不是单步调试），这样我就可以真正了解幕后发生的事情。
我已经使用 WinDbg 转储了这个过程。我现在应该使用什么命令来分析这个转储？
谢谢
您可以开始执行以下操作来获取异常的概述：
!analyze -v
现在您可以加载异常上下文记录：
.ecxr
现在...看看堆栈、寄存器、线程...
kb ;will show you the stack trace of the crash.
dv ;local variables
根据您获得的线索，您应该遵循不同的方向。如果您想快速参考 WinDbg，我建议您此链接。
我希望您发现其中一些命令和信息有用。
在使用 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 以等待管道实例变得可用。
当多个客户端同时尝试连接到命名管道时，通常会出现此问题。
我假设第 3 方 dll 是本机的（否则，只需使用 Reflector）
在使用 WinDbg 分析转储之前，请尝试使用 Process-Monitor（SysInternals，免费软件）来监视进程的活动。如果由于文件系统相关问题而失败，您可以准确地看到导致问题的原因以及失败之前它到底尝试执行的操作。
如果 Process-Monitor 还不够，您可以尝试调试您的进程。但为了查看有关第 3 方 dll 的一些有意义的信息，您需要它的 pdb。
设置正确的调试符号后，您可以使用 k 命令或其变体之一查看调用堆栈（同样，我假设您正在谈论本机代码）。如果您的进程确实因该 dll 而崩溃，请检查您传递给其函数的参数，以确保问题不在您这边。我猜想，在调用堆栈的更深处，您会到达一些 Win32 API - 检查 dll 函数传递的参数，尝试查看是否有“气味”。如果您有 dll 的私有符号，您也可以检查它的函数的局部变量 (dv)，这可以为您提供更多信息。
我希望我给了你一个好的起点。
这是使用 WinDbg 分析崩溃的绝佳资源，可能会有一定用处：https://www.networkworld.com/article/953697/how-to-solve-windows-10-crashes-in-less-比一分钟.html
本文适用于 Windows 10，但它包含指向早期版本 Windows 的类似信息的链接。