Analysing crash dump in windbg

Question

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 step

Answer 1

This is an excellent resource for using WinDbg to analyze crashes that may be of some use: http://www.networkworld.com/article/3100370/windows/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.

Answer 2

You could start doing as follows to get an overview of the exception:

!analyze -v

Now you could load the exception context record:

.ecxr

And now... just take a look at the stack, registers, threads,...

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

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.

Answer 3

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.

Answer 4

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:

.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

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.

Answer 5

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.