After getting a fresh copy of Visual Studio 2010 Beta 2, I was dying to see the amazing IntelliTrace feature. You know IntelliTrace as Historical Debugging, but consider HD as the code name. No matter what the marketing people call it, IntelliTrace is the single most important feature in the Visual Studio 2010 release. The ability to get a history of application execution through a flight recorder-like mechanism is the one feature that will save you countless hours. A WPF-based editor is nice, but IntelliTrace is what’s going to make you real money at the end of the day.

For this article, I just want to concentrate on the new parts of IntelliTrace in Beta 2. For more information on using IntelliTrace, check out Habib Heydarien’s excellent series. Additionally, I wrote a detailed article about how IntelliTrace worked under the covers you might want to read also.

From a UI perspective, you will see very few major UI changes between Beta 1 and Beta 2, but there has definitely been a lot of polish applied to the existing features. Since Microsoft traditionally sets UI freezes at Beta 2, we probably won’t see any additional major changes either. The most important difference you’ll see is in the IntelliTrace Event option page.

Back in Beta 1, once you changed the IntelliTrace events you wanted to collect, that was the change forever. I could see that causing many problems on teams using IntelliTrace because there was no baseline. Fortunately, there’s now the Restore button that will reset your collection plan back to the out of the box default.

The biggest change you’ll notice with IntelliTrace is that it certainly feels much faster. As Visual Studio 2010 is still in beta, I haven’t looked at any raw performance numbers, but compared to Beta 1, things zip right along. Of course, with a tool like IntelliTrace, you control the performance based on how high you turn the events collection knob. Turning on events and call information requires additional overhead so everything will obviously run slower. As I’m debugging more with IntelliTrace, I’m finding that I like having all of the knobs turned up to 11 so I capture everything. My thinking is that since reproducibility is hard, I’d rather pay the runtime performance hit instead of missing that one run that duplicates the problem.

In the IntelliTrace Events option page, you’ll see a few more defined events than we had in Beta 1. They include the Gesture group, which records items such as menu click events, button clicks, and other UI interaction with your ASP.NET, WPF, and Windows Forms applications. Environment variable accesses are also new. The last event I want to point out is User Prompt. That great event says the applications displayed a Windows Forms or WPF message box as well as the return value from the message box. Since a message box usually means a problem, having that event is very useful.

If you read my article on how Historical Debugging, ahem IntelliTrace, works under the hood, you’ll remember that the most important file is CollectionPlan.XML, found in <Visual Studio Install Directory>Team ToolsTraceDebugger Toolsen. That file defines everything that IntelliTrace will collect. Other than a few name changes to some elements, everything I wrote about how the file set things up and performs custom data analysis with the IProgramableDataQuery element is all the same. My mind is spinning like crazy on some cool tools that will make it easy to extend and manipulate the collection plan. Keep watching this space for more discussions of those ideas.

As you start using IntelliTrace, you’re going to love it, but one thing is going to drive you a little crazy. While doing active debugging, the IntelliTrace recording is front and center so you can jump back in time to study the program events and flow to your heart’s content. However, the instant your program ends, the IntelliTrace window and the last recording file disappears with no way to keep it visible. At first, I would just scream “Noooooooooooooooooooooooooooooo!” because I desperately wanted to look at that run to verify what just happened after my program ended. Fortunately, it’s an easy problem to rectify.

All the IntelliTrace runs collected under the live debugger are stored in the location specified in the IntelliTrace Advanced property page, Location of IntelliTrace Recordings, so they are not hard to find. To open previous runs, do a File, Open, and navigate to where your runs are stored. In the File Open dialog, sort by date and open the latest .TDLOG file.

An aside: if you’re doing full system backups with a great tool like Windows Home Server, you’ll probably want to exclude the directory where you’re storing your IntelliTrace recordings. IntelliTrace defaults to deleting any recording files when you exit Visual Studio, but if the IDE is running while the backup starts, backing up hundreds of megabytes in .TDLOG files you don’t need is a big waste of time and space. While I’m thinking about it, I don’t quite understand why the default directory for IntelliTrace recordings is not one off the user’s TEMP directory. There’s nothing stopping you from changing it, as most backup programs skip the user’s TEMP directory by default.

While you can manually perform those steps to open up the last recording file, it’s screaming for automaton. Below is a macro that you can add to your copy of Visual Studio 2010 to open the last IntelliTrace recording. I know it is probably impossible to change the UI at this point, but I really, really, hope that an option to keep the last debugging session log file open makes its way into RTM of Visual Studio 2010.

For those of you that haven’t looked at Visual Studio 2010 macros, they are going to look very familiar. As far as I can tell, the macro system is identical to that in Visual Studio 2008 so that means no writing macros in C#, which is a bummer. Maybe by Visual Studio 2025 we’ll be able to write macros in any .NET language. Oh, since macros are all Visual Studio 2008, you can’t use any of the cool new VB features in your code like automatic line breaking either. Finally, while it’s probably a beta thing, the help system is broken in the Visual Studio 2010 macro editor.

”””””””””””””””””””””””””””””””””””””””’
‘ IntelliTrace Helper – John Robbins – [email protected]
‘
‘ OpenLastIntelliTraceRecording
‘ – Opens the last IntelliTrace log file from the user’s recording path.
‘     Now you can relive your debugging sessions! I whipped this up because as
‘     soon as debugging ends, the IntelliTrace log disappears.
‘
‘ October 19, 2008 – Version 1 for Visual Studio 2010 Beta 2
”””””””””””””””””””””””””””””””””””””””’
Imports System
Imports EnvDTE
Imports EnvDTE80
Imports EnvDTE90
Imports EnvDTE100
Imports System.Diagnostics
Imports Microsoft.Win32
Imports System.IO
Imports System.Collections.Generic

Public
Module IntelliTraceHelper
    Private k_IntelliTraceAdvancedKey = _
                “SoftwareMicrosoftVisualStudio10.0DialogPage” + _
                “Microsoft.VisualStudio.TraceLogPackage.ToolsOptionAdvanced”
    Private k_IntelliTraceRecordingPath = “RecordingPath”
    Private k_IntelliTraceWildCard = “*.tdlog”

    Public
Sub OpenLastIntelliTraceRecording()
        ‘ First we have to find where the user is storing the files.
        Dim advancedKey As RegistryKey = Registry.CurrentUser. _
                                        OpenSubKey(k_IntelliTraceAdvancedKey)
        If (advancedKey IsNot
Nothing) Then

            Dim location As
String = CType(advancedKey. _
                             GetValue(k_IntelliTraceRecordingPath), String)
            If (String.IsNullOrEmpty(location) = False) Then

                ‘ Get all the files out of the directory.
                Dim fileNames As String = Directory.GetFiles(location, _
                                                        k_IntelliTraceWildCard)

                If (fileNames.Length > 0) Then

                    ‘ Assume the first file is the latest.
                    Dim latestFile As FileInfo = New FileInfo(fileNames(0))

                    ‘ Hunt through looking for the latest.
                    For i As
Integer = 1 To fileNames.Length – 1
                        Dim currentFile As FileInfo = New FileInfo(fileNames(i))
                        If (currentFile.LastWriteTime > _
                                latestFile.LastWriteTime) Then
                            latestFile = currentFile
                        End
If
                    Next
                    ‘ This is the non-obvious way to open a file through the
                    ‘ automation model.
                    DTE.ItemOperations.OpenFile(latestFile.FullName)
                End
If

            End
If

        End
If

    End
Sub

End
Module

 

Once you’ve opened a .TDLOG file, it’s not completely obvious what you need to do to look through it. The summary page will show the thread running time as well as tables at the bottom for other information.

To look at the events, or call information if collected, double click on the thread you are interested in analyzing. When I first opened a couple of .TDLOG files, I was pressing F5 because I was assuming that would load the data. I guess old habits are hard to break.

What is interesting once you have an IntelliTrace recording file loaded that contains call information, you have multiple ways to navigate the recording. In the IntelliTrace window double click on the event of interest and you’ll go directly to the source line of that event. You can also navigate with keystrokes. Using the General Development settings (which everyone should be using) the F10 key steps through the recording stepping over calls. Pressing F11 will step into calls. It’s an entirely intuitive way to navigate through a recording file and it is great how all the debugging windows update with data as well. To step out of a method backwards, use SHITFT+F11 and to set line-by-line backwards, use CONTROL+SHIFT+F11. All of those are the same key stokes when doing live debugging with IntelliTrace, but it’s nice they work even if you’ve just opened a recording log.

To move in the recording to a particular source line or method, right click on the line or somewhere in the method, and in the context menu, you’ll see two new menu choices as shown below.

Choosing either of the search options will scan through the IntelliTrace recording and show an information bar (a la Internet Explorer) showing you all the locations for that line or method.

In the above screen shot, IntelliTrace is showing that there were 417 calls to the AddNewFilesToDirectoryNode method in the recording. What I like about the information bar is clicking any of the directional arrows moves the debugging context to that location in the IntelliTrace recording and all the debugging windows report the data such as parameters and call stacks. In the case of my example function, it was trivial to move quickly through the calls to AddNewFilesToDirectoryNode to find the call where the directory parameter had exactly the value I wanted to continue my analysis.

I like the approach the team has taken for navigating through the IntelliTrace recording, but if I had a magic wand, I’d see if I could come up with a way where you could set a “breakpoint” on source line and add two key strokes. The first plays forward like F5 in live debugging, and another that play’s backwards in the recording (how cool would that be!?). It seems like a lot of the support is already there so I hope it’s something the team could add quickly. Of course, there’s probably a lot of technical information that I’m not privy to as to why it’s not there already. I hope breakpoints in IntelliTrace recordings could be done by RTM, but I’d be willing to wait for SP1 to get them, but no longer. <grin!>.

Since I’m completely in feature wish land another great feature that just popped in my head is since an IntelliTrace recording with call information includes the source and line information in it, I’d love a tool that would build a .COVERAGE file out of the .TDLOG recording. With the IntelliTrace recording hooked into unit testing and the new test manager, I think the more ways we have to get coverage data the better.

The more I’m using IntelliTrace, the more time I spend analyzing the recordings instead of using the live debugger to do that same analysis. The fastest way to debug the code is to read the code and the IntelliTrace recordings make it far easier to read because you have the execution flow, which is not always obvious, readily available. After working on a couple of projects where I was fixing bugs and adding features to existing programs, my guess is that I’m spending 25% less time live debugging and it definitely feels like I’m solving problems faster. When you realized that IntelliTrace is actually a 1.0 release, its impact completely amazes me. IntelliTrace is the reason why you need to start using Visual Studio 2010 in production today.