How is WinDbg used, what exactly is it, and does it relate to .dmp files?

Question

In the past, I have heard references to parsing .dmp files using WinDbg (I think - I might be wrong).

I have also done fairly extensive debugging with the help of .map files, and I have done extensive debugging using standard logical heuristics and the Visual Studio debugger.

However, occasionally, the program I am developing crashes and creates a .dmp file. I have never been able to interpret the .dmp file. A while ago, I posted a SO question regarding how to interpret .dmp files ( How to view .dmp file on Windows 7? ), but after somewhat significant effort I was unable to figure out how to interpret .dmp files using the answer to that question.

Today, I was viewing an unrelated SO question ( C++ try/throw/catch => machine code ), and a useful comment underneath the accepted answer has, once again, made reference to WinDbg.

If you really want to find this out though, it's easy - just trace through it in WinDbg

I would like to follow this advice. However, for me, it's not easy to "just trace through it in WinDbg". I've tried in the past and can't figure out what exactly this means or what to do!

So, I'm trying again. "For once and for all", I would like to have plain-and-simple instructions regarding:

1. What is WinDbg
2. Assuming WinDbg is related to .dmp files, what exactly is a dump file and how does it relate to WinDbg (and correct me if my assumption is wrong)
3. How do you create .dmp files and, correspondingly, how do you use WinDbg to analyze them (again, correct me if I'm wrong about the relationship between WinDbg and .dmp files).

If you could please answer this question from the "starting point" of a programmer who ONLY has Visual Studio installed and running.

Thanks!

Answer 1

1. WinDbg is a multipurpose debugger. It can debug a live process by attaching, set breakpoints, etc like you would with any other debugger. It can also analyze crash dump files as well, which are .dmp files. It functions by you giving it commands.

2. A .dmp file is a memory dump of something. What that something is depends on what the memory dump is for. It could be for a process, for example. It could also be for the kernel. What is in the memory dump depends, too. In your case, it's probably what your process looked like at the time of it crashing. What the memory dump contains can vary depending on the dump type.

3. There are various ways. On Windows Vista+, Server 2008+ - you can do it right from the task manager. Right click the process, and click "Create Memory Dump". WinDbg can make a memory dump from a live process too by using the .dump command. Other tools like adplus can be used to automatically create a memory dump on certain conditions, like when a process exceeds a memory or CPU threshold, or when it crashes.

WinDbg can open a Crash Dump easily enough. What is important is that you get your symbols loaded correctly, first. Usually in the form of .pdb files or from a symbol server (though not necessary, or always possible, it is greatly helpful).

Once you have WinDbg running, take a look at the list of commands available to poke around in your crash dump.

Answer 2

1. WinDbg is a Gui version of the command line debugger cdb.exe, both are user-process and kernel mode debuggers, it uses DbgHelp.dll to issue commands to your application or NT kernel (you can also do the same as it has an api).
2. .Dmp files are memory dumps of varying detail, some can have minimal detail enough for call stacks of all threads, whilst others will put the entire user-mode memory, handle information, thread information, memory information etc.. see this for more info. So dump files have nothing to do with WinDbg, other than it can open them, incidentally you can open .dmp files in Visual Studio
3. Like @vcsjones has already stated you can do this using task manager (at least you can from Vista onwards), you can use procdump, you can do this once WinDbg is attached, I usually do a full mini dump like this: .dump /ma c:\mem.dmp, you can also set Windows to do this when a crash happens using Dr. Watson

However, you must have the symbols for Windows and your application in order to be able to generate sensible call stacks, note that for obvious reasons you cannot step through or set breakpoints in a a memory dump, you can only do this for a live process. You can also have WinDbg attach non invasively, so Visual Studio could be attached and you can attach WinDbg non invasively and use the toolset in WinDbg to assist debugging.

For me the main advantage of WinDbg is its free, it is a small download and install, it is fast, it has a very rich toolset for diagnosing problems that are either difficult or impossible to do using visual studio.