Visual Studio Debugging Tip: Tracepoints
Posted by Stefan on November 15, 2009
If you are the kind of developer that writes bug-free code, then you have no reason to waste your time reading this. Better go and write some more of your perfect code. This article is for the rest of us who have to spend some time in the debugger, trying to figure out what’s wrong with the code.
Still reading? Good… Visual Studio comes with one of the best debuggers out there. It supports both native and managed code and you can even extend it to support custom languages. For example the IronPython team added support for python scripts.
This is the first of a series of posts where I’ll try to discuss some of the Visual Studio’s debugger features. John Cunningham said that “Some of the best debugger features are always hidden behind the right click.” One of this features is tracepoints.
A tracepoint is a breakpoint that performs an action on your code. To insert a new tracepoint, right click on the line of code where you want to insert it and select Breakpoint –> Insert Tracepoint. This will open a window that will allow you to configure the tracepoint.
This window will allow you to specify the action to be performed when the tracepoint is hit. Most often a tracepoint will be used to print some information. You can print variable values but also a variety of program state types: program locations, thread info, etc. For more advanced actions you can specify a predefined macro to be executed.
For example let’s consider the following code snippet
The tracepoint is set to print "--> Iteration {i}: {number}" and continue execution. When the program is executed, the output window will show something like this
You can see how easy is to trace the evolution of a variable during program execution. This becomes even much more interesting when you do the same with stack traces or thread information.
One can argue that the same thing can be achieved with a logging system. The advantage of tracepoints over log messages is that you can easily set and then modify them during the same debugging session. No need to stop the debugging session, insert log messages and then recompile and restart the application.
If you want to fond more about tracepoints check out the MSDN documentation about Breakpoints and Tracepoints.
