IntelliTrace Experience

[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.