 On today's Visual Studio Toolbox, Mark Downey and I are going to explore time travel. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Mark Downey. Hey Mark, how are you? Hi there. I'm doing good. Thanks, how about you? Great. Joining us on Teams from where are you at? Ohio, the Bukai State. Excellent. Mark is a PM in Visual Studio Land focusing on Azure and Diagnostics. We're going to talk about some very cool things coming in the realm of debugging. Right. We're talking about time travel debugging. Excellent. I love that name. Yes. Time travel debugging basically is our reverse debugging engine. It allows us to record a web app running in Azure, and it allows us to allow you to go forwards and backwards over a particular code. The reason why that we think that's useful is because many times when you have problems in production, you know what the error is, but you don't necessarily know the steps that we're taking to get to that error. Sometimes that's just as important as knowing what the error itself was by itself. So there's a problem in two-fold. So one, knowing what the error is and then knowing how to get there. So what we allow you to do in time travel debugging is record all the steps right up to your problem, and then that allows you to look at it within your inner loop cycle. You get to look at your problem, as if you were debugging locally, but you're really this is all happening in a sure scale. Right. I think that's a key driver of this is that the machine is running in Azure. It's running in the Cloud, it's running in a server farm somewhere else. You don't have access to that machine, and it's entirely possible of course that the machine it's running on can change from time to time because it's just a server farm. So that makes the debugging issue that much harder, right? Exactly. So we all go through that. It works on my machine. It worked in my environment. Right. It worked yesterday. Yeah. But then when we get it to scale, when we get it to Azure environments, when we get it running against a database with all these records, and when we get it with network latencies, and all the other possibilities, you don't quite know what it is happening. So what we think would be really helpful for developers debugging in production and in Azure, is to be able to see exactly the steps that are occurring in what order and then be able to use their inner development skills, inner loop development skills that they've been using before they deployed and be able to use that again even after they deployed. Cool. Let's see it. Okay. Let me start. All right. So I'm going to dive in here. I'm going to, well, I've got a simple website running in Azure, I know it's in Azure VM. It doesn't do much, but I think we'll be able to illustrate exactly why time travel debugging will be helpful. So I'm going to attach Snapshot Debugger. Refresh our memory. What's a Snapshot Debugger? So a Snapshot Debugger was our original advanced debugging technique for Azure, which allows you to take pictures of a process, right? So you could see in any line of code exactly what was going on. I can get full hydration of my Visual Studio experience, but it only takes a picture. So if a picture is worth a thousand words, our logs are those words, and we take a picture with Snapshot Debugger, and that shows you a full look at what's going on at that particular line. So we still kind of, we've used Time Travel Debugger in that same kind of vein, because now we're recording the whole thing, so a video is worth a thousand pictures. Okay, cool. So we are going to enable Time Travel Debugger for this year. Sorry, this is a 2019 feature, Visual Studio 2019? This is Visual Studio 2019 enterprise, yeah. And we're going to attach to that server. And as you can see, my service continues to be responsive. And I've been indicating now, Visual Studio is telling me I'm debugging an app in Azure, but I think it's important to indicate that this is really different to normal debugging, remote debugging, because with remote debugging, what happens, we would never do that in production, because essentially we stop the process in normal debugging, but that's not what happens with Time Travel Debugging or with Snapshot Debugging. We essentially record, but then we continue to allow you to have access to that server. So this is safe for production environments. Oh, cool. Okay, so I'm going to go ahead and put what we call a snap point here, and I'm going to configure this snap point, and what that basically is, is an indication that this method, this Cartesian product private method, is one that I'm interested in getting more detail about. And so actually I'm going to collect a Time Travel for this particular method. And what that indicates is that I want to record this method all the way through it. So if it's complicated method, I get to see every single step within this method. So I'm going to go ahead and actually I could do this conditionally. So imagine if there were a particular user who was having an issue or a particular set of account types, I could probably key in on those account types and only record in those particular conditions. But this time I'm just going to go ahead and do a regular recording. And then I'm going to send that collection plan, that snap point over to Azure. So now Azure knows I want to collect information about this method here. And as you can see, a simple method with a couple of for loops in it. Right. So I need to trigger the recording of this particular method. And I'm going to do so by activating, by activating the site so that it actually executes this particular code path. And what I'm looking for is for a recording to start. And there we go. We've got a recording captured right here. In fact, we've got two indications. We've got one here. There's a check point where our snap point was. And then we've got a recording here. So it's telling us that we've recorded successfully. Okay. So I'm going to go ahead and start debugging. And that will pull down that recording and allow us to essentially attach to that recording. And remember, this is not like remote debugging in that we don't stop the process when we are debugging. So essentially we're able to go back and forth with the site. Other users are able to interact with the site. It doesn't impact them in any way. So right now, what's happening is that I'm loading all the symbols associated with this project. That's essential because the PDBs are essentially what keeps track of what lines of code we're hitting. So we have these instructions in memory, but we've got no way of really knowing what those instructions mean to a CS file. So it loads all of our PDBs and it basically makes a connection between the recording it's taken and the Visual Studio experience that we're kind of used to. And we've kind of been developing it. Okay, so this indicates right now that we're in a debugging mode. This is kind of traditionally what we would expect to see when we would be doing any kind of debugging. So I'm going to go ahead and put in a break point here right at the very end. Just to show you, I'm going to hit the continue button and drop all the way down. And now what I'm doing now is debugging the recording. And again, just to re-emphasize, I'm my site's completely live. It's able to continue to serve my customers just fine. So this is not live debugging. You haven't stopped the app. You've recorded what happened and then you set a break point inside the recording and you're kind of offline debugging what just happened. Very cool. Exactly. So now I can go and see exactly what led up to us. Right now I can see in my local's window, I've got the results that I was about to return from this. It looks like it's eight, but I can go back to almost the start and kind of see where I started from. So the results now I'm back where it was known just where we first started. I can do something like set a break point here and actually set a conditional break point, right? So maybe I wanted to know what was happening in this inner loop here, in this for each loop. So I can set a conditional and I can say what was happening when, excuse me, what was happening when I was equal to zero and J was equal to one, let's say. And I can use my continue button to drop down into there and see any particular moment in time. So everything's recorded and this will also record if a method was called from this method, right? And I get to use all of the new features from Visual Studio. So for example, at this point, I could use the search depth feature we added in Visual Studio 2019 and say how many properties or values have the word pie in it? And I can kind of scroll through my results. So I almost kind of get a full, actually get kind of an even better experience than I do with debugging. So I'm going forward and backward with full fidelity, every single line that was executed. I get access to my call stack. I can see a list of my break points I've set. I can use the immediate window to check out different variables that may be in scope at this moment. I get everything I need to see exactly what was going in production and in some problematic situation. Do you get to see things like threads and memory usage and all that as well? Is that captured? Well, this actually is recorded a single thread in this instance. So what we actually see in this particular example are the effects of a single call and the effects on. So a thread could make a call into this thread, but essentially we've recorded this thread. That makes sense. Now, there was a feature that was similar to this. I think it was Intellitrace, right? Didn't that give you the ability to do that? So how does this compare to that? So Intellitrace is a great product, but Intellitrace relied on us taking snapshots at particular moments in time. So it's almost like you're leaving crumbs behind at every so often, right? So Intellitrace gave you the ability to get these snapshots of a running process, but it wasn't a continuous process. This is, like I said, the difference between a recording and taking several pictures, right? So you could take 10 pictures in a row, but recording a continuous sequence kind of gives you much more fidelity, much more detail. I see. So as I said, with this particular kind of process now, I can do things like step into, I can step backwards, I can step forwards, I can step into and out of various methods that this may call. But again, we think that this kind of detail and pulling it into you in a loop will give developers a really, really good experience when it comes to debugging and figuring out what issues are happening in Azure. So does this work with just web apps at the moment? Will it work with additional pieces of code like logic apps or functions or et cetera? So as of right now, we are focused on the Azure VM scenario with web apps. We are obviously very interested in pushing other scenarios and making sure we've kind of covered fully the Azure stack. But right now we're focused on Azure VMs. We are currently previewing and so we're taking this opportunity to kind of solicit feedback. So genuinely if developers get onto our sites and kind of provide feedback, it kind of drives what kind of we'll be doing next. Okay, and it's the features in preview. So is it an extension that's in preview? Is it, do you have to be using a preview of Visual Studio? How do you get this? So we had Visual Studio 2019 Enterprise. It's actually a preview feature in the release of Visual Studio 2019. So if you've got Visual Studio 2019, you've got this preview feature embedded here. And then if you want additional iterations of the preview of snapshot debugging, then you could get those from future previews of future Visual Studio release. That's unmouthful. I think it was clear. Yeah, yeah, no, it's exactly right. Okay. Yeah, yeah, we've got adding, always adding new features and filling out gaps that we've got in previews that are coming for Visual Studio 2019. Very, very cool. All right, anything else you wanna share? I think that's it, thank you. All right, thanks so much for doing this. Thank you for having me. Hope you enjoyed that and we will see you next time on Visual Studio Toolbox.