What are the basic settings+tasks to get started debugging in WinDbg?

To quote myself, from the question Are there any books that “teach” Win开发者_JAVA技巧Dbg?:

With the Visual Studio debugger, I know where I am at a given point, that is it is very easy and convenient to set it up so that the current breakpoint(sourcecode)+disassembly+call stack+local variables+... all make sense together. It's at this point that I'd need some advances WinDbg commands, but I feel I never get to the point where I feel sure enough about where I actually am in debugging the application to run any advanced commands.

With this in mind: Given binaries (or maybe a dump file), What are the first steps one needs to to in WinDbg to get a debugging session where you can actually analyze anything?

Which settings? Which windows? Which persistent environment variables? Etc.

---

I have written on this in the past, here: How to use WinDbg to analyze the crash dump for VC++ application?

---

After messing around some more (and more) it seems it is really down to the horrible user interface of WinDbg. I have now managed to get a standard procedure together that gets me halfway started:

I find the following settings have to be done, and the common ones can be saved to a workspace file in WinDbg:

• 1st - Set the symbol file path. This is very important and basically has to be done every time you start it. (You can pre-setup the microsoft symbols, but if you're nor using a symbol server for your private symbols, you have to manually put the path to the correct PDBs file every time you start debugging a dump file.

  Example of such a path:

  C:\Windows\symbols\dll;SRV*C:\temp\symbols*http://msdl.microsoft.com/download/symbols;C:\my_debbugger\Application_X\Symbols_for_Dump_7

  The first part can be set up in the WEW file, the last part is best added with .symbols+

• 2nd - I find the following windows useful: Command Prompt, Processes and Threads, Call Stack, Locals, Watch. The Command Prompt should be the largest, as you spend most time there.

• 3rd - The Thread command ~ - look it up in the help file. It allows you to switch between threads, and by having the call stack and locals visible on the screen you should then start to get a feeling for "where you are".

• 4th - The .ecxr which shows the exception context stored in the dump.