Aaron Lerch

This was probably my favorite Visual Studio 2005 tip I learned in the Mastering .NET Debugging class I recently took. John Robbins is awesome. This tip lets you set a breakpoint at any arbitrary location - no source code required! Think framework library, or 3rd party library, or any commonly called code (that you don’t have source for) where you don’t want to set breakpoints on every single call into the code.

There are a couple of gotchas that have to be configured for this to work. I was scratching my head wondering why this didn’t work for me immediately, here’s why.

First, make sure the “Just My Code” setting is turned OFF in the Visual Studio settings (Tools -> Options -> Debugging). In fact, just leave this setting off all the time — it sucks.

Secondly, make sure you have a symbol path configured so you can load the appropriate symbols. You must have symbols for the “source-less” code! The symbol path/server is specified via an environment variable named “_NT_SYMBOL_PATH“. If you don’t have a symbol server configured (more on that in a later post) your environment variable will probably look like this: (see the previous link for the exact syntax)

_NT_SYMBOL_PATH = SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols

You can also configure symbols from within Visual Studio in the Tools -> Options -> Debugging -> Symbols configuration:

Now, start debugging your application (have it break on the first instruction of the app). This is especially important if Visual Studio hasn’t yet pulled down the symbols from the symbol server. Bring up the breakpoint window in Visual Studio (CTRL+B) and type in enough detail for the resolver to find the method/property you’re looking for. If you want to break on a property, be sure to use the method syntax for the property: “get_[propertyname]” or “set_[propertyname]”.

Hit OK, and, if you had “Use Intellisense to verify the function name” selected, press “Yes”:

At this point, if your code calls the method or property, the debugger will break on it and take you to the Disassembly view. You can use the Call Stack window to traverse up to whatever point you care about. Notice also that in this example, “child” breakpoints were automatically set on all the overloaded methods for System.Console.WriteLine, automatically.

This is an awesome trick, one that can save you loads of time! Thanks John!