分析 Windbg 中的故障转储
我正在使用第三方闭源 API，它会抛出一个异常，指出“所有命名管道都忙”。
我想进一步调试（而不是单步调试），这样我就可以真正了解幕后发生的事情。
我已经使用 WinDbg 转储了这个过程。我现在应该使用什么命令来分析此转储？
谢谢
I am using a third party closed source API which throws an exception stating that "all named pipes are busy".
I would like to debug this further (rather than just stepping through) so I can actually learn what is happening under the covers.
I have taken a dump of this process using WinDbg. What commands should I now use to analyse this dump?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
您可以开始执行以下操作来获取异常的概述：
现在您可以加载异常上下文记录：
现在...只需查看堆栈、寄存器、线程...
根据您获得的线索，你应该遵循不同的方向。如果您想快速参考 WinDbg，我建议您此链接。
我希望您发现其中一些命令和信息有用。
You could start doing as follows to get an overview of the exception:
Now you could load the exception context record:
And now... just take a look at the stack, registers, threads,...
Depending on the clues you get, you should follow a different direction. If you want a quick reference to WinDbg I'd recommend you this link.
I hope you find some of this commands and info useful.
在使用 Windbg 进行事后调试时，在决定深入挖掘之前运行一些常规诊断命令可能会很有用。这些应该是您的第一步：
这些命令通常会为您提供所发生情况的概述，以便您可以进一步挖掘。在处理没有源代码的库的情况下，将生成的日志文件以及二进制库的版本号发送给供应商应该足以让他们追踪到已知问题（如果有）。
In postmortem debugging with Windbg, it can be useful to run some general diagnostic commands before deciding where to dig deeper. These should be your first steps:
These commands typically give you an overview of what happened so you can dig further. In the case of dealing with libraries where you don't have source, sending the resulting log file to the vendor along with the build # of the binary library should be sufficient for them to trace it to a known issue if there is one.
当客户端为现有管道调用 CreateFile 并且所有现有管道实例都繁忙时，通常会发生这种情况。此时CreateFile返回错误，错误码为ERROR_PIPE_BUSY。此时正确的做法是使用超时值调用 WaitNamedPipe 以等待管道实例变得可用。
当多个客户端同时尝试连接到命名管道时，通常会出现此问题。
This generally happens when a client calls CreateFile for an existing pipe and all the existing pipe instances are busy. At this point CreateFile returns an error and the error code is ERROR_PIPE_BUSY. The right thing at this point is to call WaitNamedPipe with a timeout value to wait for a pipe instance to become available.
The problem generally happens when more than one client tries to connect to the named pipe at the same time.
我假设第 3 方 dll 是本机的（否则，只需使用 Reflector）
在使用 WinDbg 分析转储之前，尝试使用 Process-Monitor（SysInternals，免费软件）来监视进程的活动。如果由于文件系统相关问题而失败，您可以准确地看到导致问题的原因以及失败之前它到底尝试执行的操作。
如果 Process-Monitor 还不够，您可以尝试调试您的进程。但为了查看有关第 3 方 dll 的一些有意义的信息，您需要它的 pdb。
设置正确的调试符号后，您可以使用 k 命令或其变体之一查看调用堆栈（同样，我假设您正在谈论本机代码）。如果您的进程确实因该 dll 而崩溃，请检查您传递给其函数的参数，以确保问题不在您这边。我猜想，在调用堆栈的更深处，您会到达一些 Win32 API - 检查 dll 函数传递的参数，尝试查看是否有“气味”。如果您有 dll 的私有符号，您也可以检查它的函数的局部变量 (dv)，这可以为您提供更多信息。
我希望我给了你一个好的起点。
I assume that the 3rd party dll is native (Otherwise, just use Reflector)
Before using WinDbg to analyze the dump, try using Process-Monitor (SysInternals, freeware) to monitor your process's activity. if it fails because of a file system related issue, you can see exactly what caused the problem and what exactly it tried to do before failing.
If Process-Monitor wasn't enough than you can try and debug your process. but in order to see some meaningful information about the 3rd party dll you'll need it's pdb's.
After setting the correct debug symbols, you can view the call stack by using the k command or one of it's variations (again, I assume you're talking about native code). if your process is indeed crashing because of this dll than examine the parameters that you pass to it's function to ensure that the problem is not on your side. I guess that further down the call stack, you reach some Win32 API - examine the parameters that the dll's function is passing, trying to see if something "smells". If you have the dll's private symbol you can examine it's function's local variables as well (dv) which can give you some more information.
I hope I gave you a good starting point.
这是使用 WinDbg 分析崩溃的绝佳资源，可能会有一定用处：https://www.networkworld.com/article/953697/how-to-solve-windows-10-crashes-in-less-than- a-minute.html
本文适用于 Windows 10，但其中包含指向早期版本 Windows 的类似信息的链接。
This is an excellent resource for using WinDbg to analyze crashes that may be of some use: https://www.networkworld.com/article/953697/how-to-solve-windows-10-crashes-in-less-than-a-minute.html
The article is for Windows 10, but it contains links to similar information for earlier versions of Windows.