Surprisingly, I don't recall seeing many blog entries about debuggers so I guess I'll start.  I use the following debuggers on a semi-regular basis, each of which have their own strengths and weaknesses.  While everybody knows about the first, you may not be as familiar with the others.
 
Microsoft Visual Studio (http://msdn.microsoft.com/vstudio/).  Whether you're using VS6, VS.NET, or Whidbey, Visual Studio has one of the best interactive debuggers around.  I spend about 90% of my debugger time in Visual Studio.  It's not just for tracking down bugs, but also good for stepping through unfamiliar code and verifying edge cases that are otherwise difficult to test.  Chances are if you're a Windows developer you use this debugger all the time, so here are a few tips just in case you don't already know them:
  • Add the @err pseudo-register to your watch window to see the value returned by GetLastError()
  • Use the pair @clk, @clk=0 in your watch window to get a quick estimate of how many clock cycles functions take.
  • If you're debugging code and an assert is getting in the way, patch the int 3 to a nop by entering *(unsigned char*)eip in the watch window and change the value from 0xcc to 0x90.
 
cdb / ntsd / WinDbg / kd (http://www.microsoft.com/whdc/ddk/debugging/default.mspx).  I lump these together because they all use the same underlying debug engine.  The breakdown is:
  • cdb and ntsd are user-mode debuggers.  They're virtually identical except that ntsd opens a new window.  (Note that the version of ntsd that ships with XP is a very old and limited version.)
  • kd is the kernel debugger.  Usually you use this from a second machine that is attached to the debugee via. a serial cable or Firewire.
  • WinDbg ("windbag") puts a bit of a GUI on top and can do both user-mode and kernel debugging.  I might actually use it if it had docking windows.
These are Microsoft's lean and mean console-based debuggers and they're particularly useful for post-mortem and remote debugging.  For example, applications shipped by Microsoft undergo thousands upon thousands of hours of stress testing.  It's not practical to have VS on each of the machines or have developers running around debugging.  Instead, every stress machine is outfitted with one of these debuggers, and if there is a crash then mail is automatically sent to a group of developers who can, at their desk, connect to the machine and debug it.
 
The downside is usability.  The commands are rather cryptic (I say this as somebody who loves the command line) and it takes more effort to construct a mental model of the program because you don't see a nice friendly source view.  However, my experience is a bit tainted because 90% of the time that I use these debuggers it is when I'm debugging optimized code -- usually somebody else's.  This means that not only do I not know anything about the code, I have to actually work to get the basics like a good stack trace, find the this pointer, find local variables (if they're still around), etc.
 
Once my new web page is up I'll post a link to my debugging cheat sheet for cdb.
 
 
OllyDbg (http://home.t-online.de/home/Ollydbg/).  Unlike the other two this isn't from Microsoft, but it's a very interesting debugger that has some unique capabilities.  It's a freeware app developed by a single person and its primary strength is working with code that you don't have the source for.  It does superb job of disassembling apps and augmenting the dissasembly with analysis that includes visual indications of function entry and exit points, loops, switch statements, common Win32 API calls and window messages (including cracking the parameters!), dynamically showing current stack, good tracing/logging, and support for patching.  When you step through code it shows you even more.  I think it supports both Microsoft and Borland symbols, if you have them.
 
Before XP shipped my team did a brief stint helping the Application Compatibility team debug and fix applications that weren't working properly on XP.  For me OllyDbg was a godsend and allowed me to successfully debug 3rd party applications that other devs had given up on using cdb / kd.
 
 
The perfect debugger would combine the UI and usability of VS, the power of cdb / kd, and the assembly analysis of OllyDbg.  Barring that, I think we should hire the guy who works on OllyDbg and replace WinDbg with a cross between the two apps.  :-)