Read Matt Nunn's guest editorial "The Time Is Now to Focus on Software Quality" here.
Maurice Wilkes, builder and designer of EDSAC, the first computer with an internally stored program, once said "…the realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs.” [1]
I'm sure that, for Mr. Wilkes, this was a fairly depressing realization, and one I think applies to most computer programmers. After all, most of us got into this business to create, not to debug. However, we all know that part of the process of bringing a new piece of software to life is ensuring that it's bug free, or at least risk free. We also know that long periods of debugging can get in the way of creating our masterpiece.
As software development tools have become more advanced over the years, debugging and debuggers have seen some of the more significant enhancements. If you once debugged by inserting print statements in your code so you could see the value of your variables, then you know that F5 debugging, watch windows, call stacks, and the like are light years beyond those days. But one fundamental debugging feature has remained constant: debugging is a linear process and you can only go forward.
In Visual Studio, a typical debugging session involves using the debugger to step through the code execution while you watch variable states and execution flow to try and identify the bug's cause. For a developer this means setting a breakpoint at some point in the code prior to the error occurring.
The trick is to set the breakpoint close enough to the error that you don’t spend hours stepping through code that has nothing to do with the error, while hoping that you set it early enough to catch the cause of the error so that you don’t have to restart the debugging process. As you know, this is a fairly "hit and miss" exercise and although you might set the breakpoint so that you can step through the actual error, the root cause of the error might have happened many steps before your breakpoint. This leads to a frustrating dance with the debugger: every time you make a wrong step, you must reset and start again. And if you're lucky enough to determine the location of an error's root cause, extracting enough information from the code surrounding the error to understand exactly what went wrong can be difficult.
More Power to Debug
What if you could debug a program in the same way that you watch a movie or TV show on a DVR? If something doesn’t interest you, you can fast forward to a new spot and if you miss something you can rewind. And what if you had a "More Info" button that you could press and find out more details about what was happening at the point in time where the error started? Visual Studio 2010 Ultimate gives you that power.
IntelliTrace is a new capability in Visual Studio 2010 Ultimate that lets you record the execution of your code and then interact with the recording in a number of ways to make it easier to find and fix any bugs. IntelliTrace uses one of a number of diagnostic data adapters (DDAs) to record all the information about your application's execution. The level of event data collection is adjustable via DDA configuration, and may be fairly coarse grain collection, or much more fine grain collection. You'll learn more about DDAs later in this article.