>> On today's Visual Studio Toolbox,
Mark Downie and I are going to explore time travel.
[MUSIC]
>> Hi, welcome to Visual Studio Toolbox.
I'm your host, Robert Greene,
and joining me today is Mark Downie.
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 Buckeye State.
>> Excellent. Mark is a PM in
Visual Studio LAN focusing on Azure and Diagnostics.
>> Right.
>> We're going to talk about
some very cool things coming in the realm of debugging.
>> Right. Yeah, talking about time travel debugging.
>> Excellent. I love that name.
>> Yeah. So time travel debugging basically is
our reverse debugging engine.
It allows us to record a web app running in Azure,
and it allow you to go
forwards and backwards over a particular code.
The reason why 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 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're allowing you to do in
time travel debugging is record all the steps
right up to your problem and then 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.
>> Right.
>> All happening in Azure at 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.
>> Absolutely.
>> You don't have the access to that machine.
>> Right.
>> It's entirely possible, of course,
that the machine is running on can change from
time to time because this is just a server farm.
So that makes the debugging issue that much harder, right?
>> Yeah, exactly. So we all go through that.
It works on my machine.
>> Yes.
>> It worked in my environment.
>> Right.
>> Right. Then, when we get to.
>> It worked yesterday.
>> Yeah, but then,
when we get it to scale,
when we get it to our Azure environment,
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 is happening.
So what we think would be really helpful
for developers debugging in production
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 loop development skills that they've been
using before they deployed
and be able to use that again even after they deploy.
>> Cool. Let's see it.
>> Okay. Let me start. All right.
So I'm going to dive in here.
Well, I've got a simple website.
>> Okay.
>> Running in Azure, 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 Snapshot Debugger was
our original advanced debugging technique for
Azure which allows you to take pictures of a process, right?
So you could see at 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's worth a thousand words,
our logs are those words.
We take a picture with Snapshot Debugger,
and that shows you a full look
of what's going on at that particular line.
So we've used time travel debugger in that same [inaudible] because now,
we're recording the whole thing.
So a video is worth a thousand pictures.
>> Okay. Cool.
>> So we're going to enable time travel debugging, put this here.
>> This is a, sorry,
this is a 2019 feature?
Visual Studio 2019?
>> This is Visual Studio 2019 Enterprise, yeah.
>> Okay.
>> We're going to attach to that server.
As you can see, my server continues to be responsive.
I have an indication now, Visual Studio's telling me
I'm debugging an app in Azure.
But I think it's pretty 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.
>> Cool.
>> Okay. So I'm going to go ahead and put as
what we call a snappoint here,
and I'm going to configure this snappoint.
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.
So actually, I'm going to click the time travel
for this particular method.
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. 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.
Then, I'm going to send that collection plan,
that snappoint, over to Azure.
So now, Azure knows I want to
collect information about this method here.
As you can see, it's a simple method with couple of [inaudible].
>> Right.
>> So I need to trigger the recording of this particular method,
and I'm going to do so by activating
the site so that it actually executes this particular code path.
What I'm looking for is for a recording to start, and there we go.
We've got our recording captured right here.
In fact, we've got two indications.
We've got one here,
there's a checkpoint where our snappoint 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.
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 or the user 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 PDPs
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 about PDP's and
it basically makes a connection between the recording it's taken,
and the Visual Studio experience that we're used to,
and we've been developing it.
So this indicates right now that we're in a debugging mode.
This is 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 Breakpoint here right at the very end.
Just to show you I'm going to hit
the "Continue" button and drop all the way down.
Now, what I'm doing now is debugging the recording.
Again, just to reemphasize,
my site's completely live,
it's able to continue to serve my customers just fine.
>> So this is live debugging.
You haven't stopped the app.
>> Exactly.
>> You've recorded what happened and
then you set a Breakpoint inside
the recording and you're
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 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 see where I started from.
So the results now back
where it was null just where we first started.
I can do something like set
a Breakpoint here and actually set a conditional Breakpoint.
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.
This will also record if a method was called from this method.
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, pioneer?
I can scroll through my results.
So I can get even a better experience than I do with debugging.
So I'm going forward and backwards with full-fidelity,
every single line that was executed.
I get access to my Call Stack,
I can see a list of my Breakpoints 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 on in production in some problematic situation.
>> You get to see things like threads,
and memory usage and all that as well. Was 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.
So a thread could make a call into this thread,
but essentially, we record it this way if that makes sense.
>> Got it.
Now, there was a feature that was similar to this,
I think it was IntelliTrace, right?
Didn't that have 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.
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.
So you could take 10 pictures in a row,
but recording a continuous sequence
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,
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
into inner 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 etc?
>> So as of right now,
we are focused on the Azure VM scenario with Web Apps.
We are obviously very interested in pushing all the scenarios and
making sure we've covered fully the Azure Stack.
But right now, we're focused on Azure VMs.
We are currently a preview and so we're
taking this opportunity to solicit feedback.
So genuinely, if developers get
onto our sites and provide feedback,
it drives what kind of we'll be next.
>> Okay. Its the features in preview,
so is it an extension that's in preview?
Do you have to be using a preview
of Visual Studio? How do you get this?
>> So with 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.
>> Okay. So then if you want
additional iterations of the preview of snapshot debugging,
then you can get those from
feature previews of future Visual Studio,
at least that's a mouthful.
I think it was clear.
>> Yeah, that was exactly right.
>> Okay.
>> We've got always adding
new features and filling out gaps that
we've got in previews at a common for Visual Studio 2019.
>> Very, very cool.
All right. Anything else you want to 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.
[MUSIC]