Analysing crash dump in windbg-CSDN博客

Analysing crash dump in windbg

debugging - Analysing crash dump in windbg - Stack Overflow

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

debugging windbg

asked Oct 30, 2009 at 10:49

csharpdev

29722 gold badges44 silver badges99 bronze badges

Is it managed or native? Can you throw some more details?
– Naveen
Oct 30, 2009 at 13:58

Add a comment

5 Answers

Sorted by:

Highest score (default) Date modified (newest first) Date created (oldest first)

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.

answered Dec 4, 2009 at 9:57

davidag

2,57733 gold badges2323 silver badges4141 bronze badges

Add a comment

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.

answered Dec 3, 2009 at 17:37

Michael Labbé

11.4k44 gold badges2626 silver badges3434 bronze badges

Add a comment

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.

answered Oct 31, 2009 at 18:23

steve

5,62411 gold badge1818 silver badges2121 bronze badges

Add a comment

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.

answered Nov 6, 2009 at 18:35

Moshe Levi

3,3631919 silver badges2525 bronze badges

Add a comment

This is an excellent resource for using WinDbg to analyze crashes that may be of some use: How to solve Windows 10 crashes in less than a minute. | Network World

The article is for Windows 10, but it contains links to similar information for earlier versions of Windows.

edited Mar 30, 2017 at 3:23

answered Nov 6, 2009 at 18:43

boot13

15511 silver badge1010 bronze badges