Here's another good article with debugger tips:

http://geekswithblogs.net/sdorman/archive/2009/02/14/visual-studio-2008-debugging-tricks-ndash-multi-threaded-debugging.aspx

Have you ever hit Break while debugging a multi-threaded console app and the only thing VS tells you it's still on is ReadLine(), where it's waiting for some input but meanwhile some other threads are working and you can't see them? The above-referenced article showed me how to access those other threads. It's all at:

Debug menu -> Windows -> Threads

Came across this article today. It's probably very old, as it's on an ASP Classic file and has no date.

 http://www.eggheadcafe.com/articles/20050511.asp

Good stuff, I didn't know or forgot about half of that stuff. IMO, using a debugger correctly (vs. constant logging and alert pop-ups) is huge when measuring one's productivity.

Incidentally, When looking for a "breakpoints window" I ended up being rather pleased to find that there's a right-click context menu in the breakpoint gutter after a breakpoint has been set in the text editor, revealing:

• Location - Break execution when the program reaches this location in a file: File: [file path]; Line: [##]; Character: [##]; [checkbox] Allow the source code to be different from the original version
• Condition - When the breakpoint location is reached, the expression is evaluated and the breakpoint is hit only if the expression is true or has changed. [checkbox] Condition: [textbox] [radio]: Is true; [radio]: Has changed
  • Yessss!! I've SO badly needed this one, I don't know how many times I've pounded F5 while staring at my Watch window waiting for some string to show up in a loop, or actually wrote inline code like
    if (condition && System.Diagnostics.Debugger.IsAttached)
        System.Diagnostics.Debugger.Break(); // my head open against the wall
• Breapoint Hit Count - A breakpoint is hit when the breakpoint is reached and the condition is satisfied. The hitcount is the number of times the breakpoint has been hit. When the breakpoint is hit [drop-down]:
  • break always
  • break when the hit count is equal to [##]
  • break when the hit count is a multiple of [##]
  • break when the hit count is greater than or equal to [##]
• Filter - You can restrict the breakpoint to only being set in certain processes and threads. Enter an expression to describe where the breakpoint should be set, or clear the expression to have the breakpoint set in all processes and threads. You can combine clauses using & (AND), || (OR), ! (NOT), and parentheses. Sample clauses:
  • MachineName = "machine"
  • ProcessId = 123
  • ProcessName = "process"
  • ThreadId = 123
  • ThreadName = "thread"
• When Breakpoint Is Hit - Specify what to do when the breakpoint is hit.
  • [checkbox] Print a message:
    
    • sample: "Function: $FUNCTION, Thread: $TID $TNAME"
  • [checkbox] Run a macro: [macros drop-down]
  • Continue execution

Wow, that's some powerful breakpoint logic I didn't realize was right under my nose.