What is IntelliTrace?
Microsoft introduced a new feature in Visual Studio 2010 Ultimate, called IntelliTrace (previously known as Historical Debugger). What’s interesting about this tool is that it helps developers track down bugs that they might not be able to reproduce in their managed code application, for example, those that appear only once because of a web service error or a system issue.
Even though many developers still heavily rely on breakpoints to try capturing some of the errors that might appear because of unknown events, sometimes even a breakpoint won’t be able to reach the issue – after all, maybe the breakpoint won’t be hit at all.
IntelliTrace starts automatically once you run your application for a debug session – you can see the IntelliTrace sidebar in Visual Studio notifying you that debugging data is being collected.
While the application is in a debug session, you cannot view the execution data. However, every single exception, even the ones that did not crash the application, is captured. When the developer breaks the execution, IntelliTrace will display a list of events that occurred and that were registered in the log:
Basics of IntelliTrace
You can see that here the event types differ. First of all, there is a Live Event – it caused the debugger to break and it is user-triggered, so this probably isn’t going to add much value to the developer. The Debugger set of events describes events on the application level – for example, when the application is started or when a breakpoint is hit. Gestures involve user interactions – in this case, it was a button click, as you can see from the image above.
The set of events that are tracked by IntelliTrace is not limited only to basic debugging, but it also is able to capture errors that are thrown in various threads and by other .NET Framework sub-frameworks, like ASP.NET.
When developing a complex application, the developer often sees the need to track only a specific subset of events that are related to a very specific task, for example serialization or web service communication. To avoid a lot of unnecessary data, IntelliTrace offers the possibility to filter events by categories:
So in case you don’t want to track debugger events or events that were triggered by file operations, you can simply remove the checkbox from the specific category and it won’t be displayed in the IntelliTrace log.
The same principle applies to threads that are active in the current application. I am creating a sample thread that will call a MessageBox instance with a sample message:
var thread = new Thread(new ThreadStart(() => MessageBox.Show("Sample")));
thread.Name = "Test Thread";
When reviewing the debug history, you can specify which threads you want to see tracked:
Filtering debug information by threads is very useful when breakpoints fail to be the most effective solution.
Reviewing debugging data
IntelliTrace data is session-specific. Therefore, when the debug session is terminated, the data seems to not be available anymore – it is lost.
Or is it? Even although you are not seeing this data in Visual Studio, it is still available for review, since after each debugging session, the IntelliTrace history dump is created.
On my Windows 7 machine, I can see the IntelliTrace records in C:\ProgramData\Microsoft Visual Studio\10.0\TraceDebugging. You can modify this location as well as the maximum quantity of stored debugging data in Tools > Options > IntelliTrace > Advanced
In the folder I’ve mentioned, there is a set of IntelliTrace log files that can be opened and reviewed in Visual Studio. You will be able to see the timeframe for various threads, exceptions that were thrown, modules that were loaded, system information (to check the configuration of the machine where the application was debugged) and general events that occurred:
This way, you can easily compare the application activity in different debug sessions as well as easily track down bugs that are less likely to be easily reproduced.
IntelliTrace is a very powerful tool that helps solve a lot of problems connected to debugging and testing, since it offers a history of how the application worked during the debug session. In some cases, it eliminate the need in breakpoints and allows the developer to see more debugging information beyond them.