Follow @RoyOsherove on Twitter

[Rediscovered] Advanced debugging tips and stuff you never knew about the "Find" combo box

I just "re-discovered" an old post of mine relating to some cool debugging tricks. Its amazing I forgot all about these cool tricks and it was fun to rediscover them. I bet some of you could benefit from them (again).
So - as they say, "Let the recycling begin!"

1) You can set breakpoints on the callstack window as well - just select the call and hit F9 or right click. great for recursive functions.

2) You can set individual breakpoints on different expressions on the same line bye setting the cursor in the specific expression and hitting F9

3) CTRL+B - advanced breakpoint properties dialog(if you didn't know this already)

4) You can set a breakpoint directly on a specific method in a class if you know their names. Just write down the "class.method" in the "Function" tab of the breakpoint properties dialog and you'll save yourself lots of time in finding that point in code and pressing F9.


  • It's case sensitive if you're using a case-sensitive language
  • The method name might not show up in C++ debugging if it's hidden in a DEFINE
  • You must select the correct language in the breakpoint dialog.
  • Oh one more thing - if youre using managed C++ you'll have to prefix the debugging expression with "MC::" so to set a break on class MyClass with function MyFunc you'd have to write "MC::MyClass::MyFunc" in the breakpoint dialog.

5) You can write breakpoints that break on calls to the framework classes. for example - you could write in the breakpoint dialog - "Console.WriteLine" and you'll break into disassembly whenever you call that function(You'll get a long list of "child" breakpoints for each of that method's overloads in the breakpoint window)
You can also break on properties, but you'll have to prefix the property name with a "get_" or "set_" prefix.

6)(best one) Auto-search for methods to breakpoint on. In the breakpoint dialog, if you type just the name of a method that you know exists, and that method is unique in the application, you'll automatically set a breakpoint there, without the need to specify class name.
BUT - if you have overloads to that method, or it exists in more than one namespace, you get a list of all the available methods and overloads, allowing you to select on which ones you'd like to set a breakpoint, and the best part - you have an "All" button to quickly set a breakpoint on all of them.
If you'e debugging C++ - you can write the [name of a class]+ "." and you'll get a list of all members that can be debugged.
note: DON'T try this in other languages - you'll get a very nast crash if you do!

7)A few things you should have known about the "Find" combo on VS.NET's main toolbar:

  • If you type the name of a solution file or any other file that is somehow related to the project or is in the INCLUDE environment variable and then press CTRL+SHIFT+G - VS.Net will open that file in the eidotr for editing.
  • If you write the name of a method (or class.method) like in the breakpoint dialog and press F9 - you'll get the same functionlity like in the breakpoint dialog.
  • If you type in ">" in the find combo - you'll see that it turns into a run of the mill command line! (including intellisense and all)

[Much of this was learned from the book "Debugging Applications for Microsoft .NET and Microsoft Windows"]

and here's a nice tip.

Imagine getting a nasty exception messagebox (or any other message box in windows)(sounds familiar?). Try pressing CTRL+C while the messagebox is still open. then open notepad and press CTRL+V. Have fun!

Introducing the Osherove.Interception framework

Sometimes I'm simply frustrated at the qualification game