Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ WinDbg cheat sheet

Microsoft WinDbg is part of the Debugging Tools for Windows package and is a fairly powerful, and free, debugger. I like to keep it around because it's much quicker to obtain and install than Visual Studio and is sometimes more helpful for debugging crashes in cases where Visual Studio acts oddly or is otherwise unable to extract the needed information. Although it has a GUI, it's mostly a command-line debugger, and as such is used somewhat differently than the Visual Studio debugger. I've found that WinDbg is less user friendly and harder to use for interactive source debugging, but much more powerful for difficult or post-mortem situations. One useful advantage is that if the Windows GUI gets wedged -- which tends to happen when hooks with global mutexes go awry -- you can still use CDB, the command-line version of WinDbg, because console windows are specially handled by CSRSS and often don't lock up with the rest of the UI.

Anyway, the cheat sheet:

The first step you need to do generally is to get symbols hooked up for your executable or crash dump so you're not flying blind. When one or more of these are missing, use .exepath and .sympath to set the executable and symbol paths. It's very helpful to also use .symfix+ to hook up the Microsoft symbol server so you get symbols and stack unwinding information for Windows DLLs. If the debugger is stubborn and doesn't want to load symbols because it thinks they don't match, you can use .symopt+ 0x40 to set the "load anything" flag.

If you're not sure if you've got all symbols, the lm command will list all modules in the process and their symbol load status. lm -v will also display additional data including paths, timestamps, and versions, which can help you go hunt down the right symbols from the build archive.

Type ~ to dump a list of all threads. The tilde is also a prefix for thread selectors at the beginning of commands. Two useful selectors are ~n to select thread n temporarily, and ~* to select all threads. ~s changes the current thread, so to switch to thread 4, you'd type ~4s.

r will dump the current registers, in case you missed it from the attach -- and as WinDbg helpfully tells you, .ecxr will switch to the context frame of the exception that occurred, if it was captured in a minidump. If you attached the debugger because the application appears to have deadlocked, !locks will dump out a list of critical sections currently held and which threads hold them. This usually identifies the reference cycle immediately.

The command to dump call stacks is k. Generally the first thing you should do after attaching to a process or loading a crash dump and then setting up symbols is to type ~*k to dump call stacks for all threads. kb will also attempt to dump raw parameters for each call. Unfortunately, the call stack on an optimized x86 executable is often incorrect. Sometimes you can dump past a sticking point or uncover hidden calls by forcing a different starting stack address with =, e.g. k =12fc00.

db dumps bytes, dw dumps words, dd dumps dwords, etc. One of my favorite commands is dds, which dumps an array of dwords and attempts to decode each one as a pointer to a symbol. If I suspect that the automated call stack is incorrect, I do dds esp L20 and then try to reconstruct the correct call stack from any apparent return addresses in the output. It's also useful for finding vtable pointers of C++ objects. For strings, da dumps ASCII strings and du dumps Unicode ones.

When you have a valid call stack, you can use .frame to switch between the entries on the call stack, and dv to dump local variables... or you could just use the WinDbg UI for that. ? evaluates an expression using the default expression syntax (usually MASM), and ?? evaluates using C++ syntax. I prefer to use ?? instead of the watch window, because WinDbg unfortunately has a habit of checking symbols over the network a lot when evaluating expressions, and if you use the watch window it can repeatedly hang the debugger for long periods of time, whereas with ?? you have more precise control over when it happens.

Breakpoints can be set with bp, cleared with bc, and listed with bl. These are all boring PC-based breakpoints, though -- use ba to set data breakpoints, which IMO are highly underrated. t traces, and g goes (resumes execution). Ctrl+Break interrupts the application again. WinDbg doesn't bring the app to the foreground on resuming execution like Visual Studio does, which can avoid annoying loops where every time you hit go, it immediately repaints and hits your breakpoint again.

After you've gotten all the information you can locally, there are a few options. You can just give up with q, or you can try again with .restart, if you started the debuggee under WinDbg. If the program you attached to is just hung, you can use .detach and then attach Visual Studio to it. You can also use .dump to create a minidump for further analysis -- this is especially helpful since you can load the minidump offline in either WinDbg or Visual Studio, and if you create a "big minidump" with .dump /ma, you can pretty much see and do just about anything in the dump that you could locally, short of actually resuming execution.

That's about all I can think of for WinDbg essentials, although of course it comes with a nice help file that details everything I missed here. I highly recommend looking into WinDbg and adding it to your debugging arsenal, especially if you're one of those people who has to diagnose crash dumps sent by users. The last point I'd like to make is that if you're working on Windows XP, the NT system debugger (NTSD) is the ancestor of WinDbg; it's missing a lot of features in comparison, but it's always there. If you find yourself in a pinch and don't even have WinDbg available, you can attach ntsd.exe to the failed process, using -p to specify the process ID and -pv to force a non-intrusive attach if necessary, and then write a minidump with .dump.

Comments

Comments posted:


The link you posted is incorrect. It should be all lowercase:
http://www.microsoft.com/whdc/devtools/d..

Steven - 01 08 08 - 11:30


@Steven: Your lowercase version 404's, while the original mixed case one works for me.

Torkell (link) - 01 08 08 - 15:30


Both links work for me. It's probably related to Akamai caching.

ender - 01 08 08 - 16:45


The link I've got up there is the #1 hit on Google for "Debugging Tools for Windows," so, uh, don't know what I can tell you.

Phaeron - 02 08 08 - 14:30

Comment form


Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.