Yesterday, I found a couple of useful debugging tools within VS 2005, the Immediate Window and Tracepoints.

Immediate Window

Have you ever gotten an assert in your own code from an invalid operation in a Win32 API?  How do you know what the failure inside the API was?  You put in a GetLastError(), right?  What if the function is called from a library that you either can't change or don't want to recompile?  Answer: the Immediate Window (Ctrl-Alt-I).

I was recently debugging a threaded application that was failing inside of CreateThread().  Instead of rebuilding the library calling the API, I simply brought up the Immediate Window and typed in:

It immediately responded with the error, 1450.

You can call your own methods, print out variables and even create new objects.  Read the documentation for all the details, but this is a nice way to get yourself quick answers about your code.

Tracepoints

A tracepoint is a great way to quickly generate trace messages without inserting code.  This is intended for temporary debugging only as they aren't included in any shared source.

I've found this very useful in tracing multithreaded code.  It can be a pain in the rear to get print messages that is sync'd up with the execution of a line.  I haven't been able to confirm this yet, but I believe tracepoints execute and print in an automic manner.  This obviously makes it slow, but I'm suspecting that it's output would be the same as locking around execution and print without the side effect of altering the synchronization of your non-traced code.

Creating tracepoints is a two step process.  You first set a breakpoint on a line, then you convert the breakpoint to a tracepoint by adding the condition, "When hit...".  If using Visual Assist, you must convert via the Breakpoints window directly, a right click on the breakpoint will not suffice.