IntelliTrace Experience
0 (0 Likes / 0 Dislikes)
[IntelliTrace in Visual Studio 2015]
[Angelo Petropoulos, Senior Program Manager]
My name is Angelos Petropoulos, and I'm a senior program manager working in Visual Studio Diagnostics.
In this video, I'm going to take you through a tour of IntelliTrace
in Visual Studio 2015, talk to what's new,
and highlight the improvements we have made to the user experience.
First I'm going to give you a quick introduction to IntelliTrace,
explain what it is, how it works, and why you would want to use it to fix bugs.
Then I'm going to show you IntelliTrace in action,
as you watch me use it to solve a real bug.
In a nutshell, IntelliTrace is a recorder for your debugging session.
As your application is running, IntelliTrace is monitoring it for interesting events.
Some examples of interesting events are the user performing a gesture
such as clicking a button or closing a window,
accessing files such as configuration files,
executing SQL or throwing exceptions, amongst many others.
Everytime IntelliTrace detects an interesting event taking place,
it captures the call stack, along with some local variable information,
for that particular moment in time.
What this allows you to do is execute your testing steps to reproduce a bug
and then go back in time and examine the state of your application as it was
when those events took place.
Let's see how you can use this capability to fix a real bug.
In this demo, I'm using a WinForms application I downloaded from CodeProject,
but everything that you see applies to most managed project types
such as WPF and asp.net.
This application is a social club manager.
After you log in, you can register new members,
and I'm going to do just that for myself.
And after you register, you can use the search functionality
to find existing members
and to update their information.
When I click register, the application is making sure that
the necessary database tables have been created.
And after everything is in order, registration is successful.
The reason I'm using this application
is because I'm told there is a bug with the search functionality.
The application offers two different ways of searching existing members.
You can either search specifically for specific occupation and marital status fields—
and I'm going to search for myself as an engineer and married and see what that returns—
or you can use the Get All search functionality,
which I'm told is behaving a bit erratically.
People are complaining that use the Get All
they get records that they didn't expect.
Let me show you what I mean.
If I click Get All now,
I get the one record that I inserted for myself in the beginning,
plus I get a second record that has some data.
Some fields are completely blank,
and others seem to have their default values off and on.
Out of curiosity, I'm going to attempt to query for this record
using the other search method to see what I get back.
I'm going to select Unknown as the occupation and marital status,
and see if I actually get a record back.
I do get a search result, but it wasn't the one I was expecting.
I actually get the one record I inserted at the beginning of the demo.
At this point, there is many different scenarios running through my mind.
Maybe the bug is with the Get All functionality
and the SQL select statement that it executes.
Or maybe the bug is with the inserting of the record at the beginning of the demo,
and that's inserting more than one record.
Let's see what data IntelliTrace has collected for this diagnostic session.
Because IntelliTrace can only show you the data it has collected
when the debugger is in the break state so you can inspect the state of the application,
I'm going to use the Break All button from the Visual Studio toolbar.
Clicking on this is the equivalent of every thread in the application
hitting a break point in the debugging breaking execution.
In Visual Studio 2015,
IntelliTrace has been integrated into this new diagnostics tools window
that came up automatically for me when I pressed F5.
The list of events that IntelliTrace has collected
appears at the bottom of this window,
and there is a brand new visualization for IntelliTrace
of exactly the same events on a timeline.
The timeline shows you how many seconds have passed
since the beginning of the debugging session,
and it breaks the events down into three different timeline tracks.
The first one is showing me the event that the debugger
did to break execution, whether that's a breakpoint B hit
or, in this case, me clicking the Break All button.
The second track is showing me events that IntelliTrace has collected
that typically go to the output window, things like module loads,
threads exiting, and so on.
Finally, the third track is showing me every other event that IntelliTrace has collected.
If you look at the table below,
we did quite a few things with this application.
So IntelliTrace has collected quite a bit of data.
As I scroll up and down the list,
you can see that there is tons of events.
My first step is to filter down this view to the things I want to focus on.
Since I know the bug is related to me clicking on buttons
and executing SQL, I'm going to use the category filter
to unfilter every category except for ADO.NET and Gestures.
As I do that, not only is my tabular view updated and filtered to those events,
but so is my timeline here.
Now, since I did quite a few things, and I'm not really sure where the bug is
or what it's root cause is, I'm going to start looking at the beginning of the application
and see if I spot anything that I consider unexpected or unusual.
Hovering over the very first event IntelliTrace has collected
shows me clicking the Login button.
The next event is me clicking the Register button
followed by a cluster of events that I'm assuming are related to this registration.
If I move over to the next event in the timeline,
I see this is me clicking the Search button.
So I can select the time in between these two clusters of events,
and by doing so I am filtering the tabular view only to these events selected,
plus I have the opportunity to right-click Zoom to Selection
so I can get a better look at this interesting cluster of events.
Now that I've used my timeline
to orient myself, I'm going to drill into the details of the tabular view.
Looking at the list of events that IntelliTrace has recorded,
I see me clicking the Register button,
followed by a number of SQL events
that are executed as part of entity framework,
making sure that the necessary tables are created
before the records can be inserted.
Scrolling through this list, I'm trying to see where the actual insert is happening.
And as I get to the bottom, I can see that right before the very end of the list,
which is the end of my time selection,
there is two insert statements into club members,
which is the table that stores my member registrations.
Immediately, the fact that there is two of them
is alarming to me because I only clicked the button once
and I only registered one member, myself,
so I didn't expect two insert statements into the same table.
My next question is, why do I have two insert statements?
How were they invoked?
To find out, I select the first one,
and I click on Activate Historical Debugging at the bottom.
By clicking Activate Historical Debugging,
my Visual Studio editor
has now been set to a time context in the past
for when this event was actually generated.
There is an info bar at the top letting me know that there is debugging windows
that are participating in this experience,
and, in fact, if I look at my call stack window,
it says Historical Debugging in brackets next to it.
This means that the call stack window is now showing me
the call stack as it was when this event was collected.
I see that I am in the create method.
And from the call stack window, if I go a frame down,
I can see that this method was called from registered member.
That seems normal.
And going another frame down, I can see that the registered member method
was called from register_click,
which if I double-click to,
is the event handler for the Register button.
So this looks normal. This is what I expected.
I'm now curious as to what's different about the second insert statement.
If I go back into my diagnostics tools,
and I select the second insert statement,
I click Activate Historical Debugging on that one.
And I'm taken to the same line of code as before in the same method as before called Create.
Looking at the call stack window, I see that the create method
is called from the same method as before, registered member.
But if I go up one more,
I see that registered member is now being called by something different.
It's being called by buttonregister_mouseclick.
If I double-click on that frame,
I'm taken to yet another event handler for the same button.
So from this I can deduce that what's actually happening is
I have actually hooked up accidentally two different event handlers for the same mouse click.
And what's happening is, after the first member gets registered
and my form is reset, a second mouse event handler is executed,
and I'm registering a second member that is actually
full of empty and default data fields.
You just saw IntelliTrace in action.
To fully appreciate what IntelliTrace has to offer you,
think of your typical debugging workflow.
When you see a bug, your first thought is finding an appropriate place to put a breakpoint.
You then execute the steps that are necessary to reproduce the bug
and hope that your breakpoint gets hit
and that you can inspect the state of the application in the vicinity of the breakpoint
and that will hopefully lead you to the root cause of the bug.
With IntelliTrace, your first thought when you see a bug
is let's see what IntelliTrace has collected.
Hopefully just looking at the data that IntelliTrace has collected for you
will lead you to the root cause of the bug
without having to use breakpoints and without having to repeat your testing steps.
Even if the bug is hiding in between what IntelliTrace considers interesting events,
you can eliminate certain scenrios,
and you can have a better idea of where to put your breakpoint to be successful.
As you saw during the demo,
IntelliTrace is integrated into Visual Studio,
and it's part of the F5 experience.
However, IntellitTrace also has a standalone component
called the IntelliTrace Standalone Collector.
You can use it to capture the execution of an application
that is happening on a machine where you cannot have Visual Studio installed on it,
such as a production server.
You can save the execution of the application to a file
then copy the file across to your development machine,
open it using Visual Studio,
and then you get a similar experience to what you saw in the demo during F5.
That's about all the time we have today.
For more information about IntelliTrace, and everything related to Visual Studio Diagnostics,
please visit our blog which you can see on the screen behind me. [aka.ms/diagnosticsblog]
Thank you for watching.