Chapter 5. Advanced Debugger Usage with Visual Studio

In this chapter:
Advanced Breakpoints and How to Use Them	200
The Watch Window	219
Advanced Tips and Tricks	242
Summary	249

No matter how much great diagnostics code you use and how much planning you do, occasionally you need to run the debugger. As I've mentioned many times in this book, the whole key to debugging effectively is to have a purpose every time you start the debugger. Now I know that most of you will be in the debugger to fix your coworkers' code, not your own (because the code you write is undoubtedly perfect). I want to make sure that when you must resort to the debugger, you're able to get the most out of it and fix problems as quickly as possible.

Before we talk about any debugger usage, I have to mention that debuggers prove the existence of black holes. If you get in the debugger prematurely, the debugger will suck all the time out of the room. The trick to using the debugger effectively is to ensure that you have a solid hypothesis written down before you ever start. Without that hypothesis, you'll have nothing giving you that road to follow. Since all computer geeks have seen the movie "Finding Nemo," you know that Dori the Fish had an attention span of a gnat on crack and that even a bright light would distract her. The last thing you want to do in the debugger is be Dori the Debugger wandering around going "Oh, look at the shiny variable!" and being distracted from the task.

With a hypothesis written down, you'll keep focused on the potential problem turned up by source code inspection. As you find interesting information, be sure to write it down, but follow that hypothesis to its conclusion so that you prove or disprove it. When I see one of my developers in the debugger, I always ask to see his hypothesis. You need this focus to avoid the huge time drain using a debugger can be.

In this chapter, I'll talk about how to take advantage of the wonderful Microsoft Visual Studio debugger. If you've been developing for Microsoft platforms for a long time as I have, you can certainly see a marked progression of debugger improvements over the years. In my opinion, Visual Studio 2005 represents a huge jump in progress and is the state-of-the-art debugging tool. The team has done an outstanding job of combining an extremely easy-to-use user interface (UI) with power to spare for the really difficult problems. The fact that Microsoft Windows developers now have one debugger that handles JavaScript/VBScript, Microsoft ASP.NET, .NET, XML Web Services, native code, and SQL debugging in a single debugger UI is amazing.

If you're new to the Visual Studio debugger, I suggest that you read the documentation before continuing. I won't be covering the basics of the debugger in this chapter; I'll assume that you'll study the documentation if you need to. The debugger is discussed in the Visual Studio documentation under Development Tools and Languages\Visual Studio\Integrated Development Environment for Visual Studio\Building Debugging and Testing\Debugging in Visual Studio (http://msdn2.microsoft.com/en-us/library/sc65sadd(VS.80).aspx).

Before you read any further, there are two assumptions I'm making in this chapter: The first is that you've followed all the best practices I laid out in Chapter 2, "Preparing for Debugging," and, most importantly, you have set up a Symbol Server. No matter whether you're developing .NET or native applications, getting perfect symbols automatically loaded means that you'll always have an advantage in solving your debugging problems.

The second assumption is that you've turned off a "feature" of Visual Studio debugging, Just My Code. The idea behind Just My Code is vaguely interesting as the documentation says, "This feature enables you to focus on only the code you have written, and ignore code you are not interested in." However, the correct name for Just My Code is "Hide Everything From Me So I Can't Debug." This "feature" sets the debugger so you can debug only if you have symbols and the code is not optimized. Yes, you read that right, it makes it nearly impossible to debug into optimized code, and I can't see why anyone would consider this a feature of a debugger. Countless developers have asked me about problems in the debugger that come down to the fact that Just My Code is turned on by default. To turn off Just My Code, in the Options dialog box, expand the Debugging node, and on the General page, clear the Enable Just My Code (Managed Only) check box.

On a brighter note, I wanted to mention that all of the core tricks of Visual Studio's debugger that I discuss also work in Dbgclr.exe, the free GUI debugger installed as part of the Framework Software Development Kit (SDK). That's because Dbgclr.exe is made up of the same managed debugging binaries as Visual Studio.