Sorry Rive0108, I forgot about that before. OK, rewinding a bit to the beginning...
Download the debugger package that matches YOUR machine's architecture http://www.microsoft.com/whdc/devtoo...g/default.mspx
In other words, if you're running 32-bit Vista, install the 32-bit version of the "Debugging Tools for Windows", irrespective of whether you intend to debug 32-bit or 64-bit code. Vice versa for x64 - download and install the x64 package, and you'll still be able to debug 32-bit dumps. I suspect that few people would be running Itaniums around here, so don't grab the IA-64 build. "IA-64" (Itanium) is a vastly different architecture to "x64" (AMD64, a.k.a. EM64T when sold by Intel).
Override the default install path and install to c:\debuggers instead
This is entirely optional but you'll be happier, especially if you intend to do a fair amount of dump gazing. Choose the "custom" install option and use c:\debuggers (or d:\debuggers or whatever drive) as the install path. It makes it easier to work with the tools and removes that pesky "Program Files" space from the path name. The debugger package is a lot more command-line oriented than many apps nowadays.
Register WinDBG as the default handler for dump files
Another entirely optional step that makes life easier. By registering WinDBG (the main debugger you'll want to use) as the default handler for common dump file types, you'll be able to just double-click on a dump and have it open in WinDBG without having to go through the File | Open... rigmarole every time. This registration needs to be performed from an elevated CMD prompt (run CMD as administrator):
C:\>cd debuggers
C:\debuggers>windbg.exe -IA
WinDBG should fire up and pop up a dialog box that says this:
---------------------------
WinDbg:6.11.0001.402 AMD64
---------------------------
WinDbg successfully registered file assocations for .DMP, .HDMP, .MDMP, .KDMP and .WEW.
---------------------------
OK
---------------------------
Set your symbol path
This is NOT optional. In fact, getting it wrong is the #1 reason for frustration when learning to debug. There are several ways to get it right, but the one that dk70 already mentioned is possibly the simplest:
- Start WinDBG
- WITHOUT opening any dump files, click File, "Symbol File Path..."
- Set the path to be the following:
SRV*C:\SymCache*http://msdl.microsoft.com/download/symbols
It can be any valid local path, c:\Symbols or e:\MySymbols or whatever, but the SRV and http bits must be exactly as above. Don't move the local path around too much though because the idea is to build up a local cache of symbols that minimises your waiting time while symbols are being downloaded from MS. That local cache can grow quite large over time, if you do a lot of this.
- Exit WinDBG. It should ask you whether you wish to save workspace settings. "Yes" is the answer.
- Check that from now onwards the symbol file path is always set that way whenever you start WinDBG.
Opening and analysing dumps
Once you've done the preparatory steps above, you can double-click (if registered) or "File | Open Crash Dump..." in WinDBG to get it to open up and analyse a minidump or any other memory dump, including crashes from user-mode processes. If you want to re-invoke its automated analysis engine, use the !ANALYZE -V command. The "v" switch stands for "verbose" - it spews out a bit more detail.