Time Travel Debugging in Visual Studio Enterprise 2019

Original author: Mark Downie
  • Transfer
The preview version of Time Travel Debugging (TTD) in Visual Studio Enterprise 2019 allows you to record the execution of a web application running on an Azure virtual machine, and then accurately restore and reproduce the algorithm. TTD integrates with our Snapshot Debugger offering and allows you to rewind and play each line of code as many times as you like, helping to identify and predict problems that can only occur in combat environments.

The picture is taken from the Quantum Break (18+) game page in the Microsoft Store. By the way, there is a 75% discount on it ($ 10). If someone wanted but couldn’t find the opportunity, we recommend it.

The most efficient type of debugging often occurs in the so-called “inner loop”. When you view and debug code locally before you move on to version control. The problems we face during the development of the internal cycle are usually easier to understand and diagnose because they are accessible and repeatable.


Today, we are pleased to announce the release of Time Travel Debugging (TTD) in Visual Studio Enterprise. With TTD, we give you the opportunity to write code executed in a production environment and to reproduce the execution path inside Visual Studio. TTD also gives you the ability to move back and forth in time, as if you were doing local debugging of the “inner loop”. You also gain access to important debugging features such as locals and the call stack.

Modern debuggers usually allow you to stop at a certain point (breakpoint), interrupting the entire process, and only then move forward. Even with more advanced debugging tools such as IntelliTrace , you record events and data at discrete points in time. TTD has a significant advantage over snapshots, logging, or crash dump files, because these methods usually do not contain accurate information about the execution path that led to the final failure or error.

What is Time Travel Debugging?

Time Travel Debugging (TTD) is a reverse debugging solution that allows you to record the execution of code in an application or process and play it back and forth. TTD improves debugging, as you can go back in time to better understand the conditions that lead to a particular error. In addition, you can play it several times to figure out how best to fix the problem. TTD technology was recently introduced in the preview version of WinDbg for scripts with native code .

We have expanded Snapshot Debugger with TTD so you can record applications as they run. This record can then be played back in Visual Studio Enterprise 2019, where you can rewind and play each line of code as many times as you like. TTD writes to a thread that meets the snappoint conditions and is usually executed until the end of the method. But if before the end of the method after snappoint there is “await”, the recording will stop. This feature will be in the preview for the release of Visual Studio 2019 with a valid license. We plan to add more TTD scripts in future updates.

Getting started with TTD

A preview of Time Travel Debugging can be enabled in the latest version of Visual Studio Enterprise 2019 for Azure virtual machines running Windows with ASP.NET (4.8+).

After installing the latest version of Visual Studio Enterprise, follow these steps:

1. Open the project that requires Time Travel Debug - make sure that you have the same version of the source code that is published on the Azure virtual machine.

2. Select Debug> Attach Snapshot Debugger and select the Azure virtual machine on which your project is deployed along with the Azure storage account. The first time you try to connect, you will need to install the Snapshot Debugger site extension.

3. Select the Time Travel Debugging optionand click the Attach button . Once Visual Studio enters Snapshot Debugger mode, it will be able to record using TTD.


4. Create snappoint and configure it to enable Time Travel Debugging. Click Start \ Update Collection .


5. Once your Snapshot has been compiled, click View Snapshot , and you can use the command bar to go back and forth within the recorded method.


TTD Preview Limitations
At the initial preview stage of TTD, we will support AMD64 web applications running on an Azure virtual machine. We expect the entry to add significant overhead to your running process, slowing it down depending on the size of the process and the number of active threads. We also expect debugging degradation in some of the following scenarios:

  • During the compaction phase of the GC.
  • Passing through an optimized method, for example, when you enter a method that does not contain snappoint.
  • If your application internally downloads or unloads application domains.
  • Recording occurs only in the stream that was called by snappoint. Code that subsequently affects alternative threads will also be degraded.

Please note: we will not record asynchronous cause and effect relationships either.

During preliminary testing, we found that the TTD file size ranged from a few hundred megabytes to several gigabytes, depending on the duration of the session and the duration of the web application. However, the files created by TTD will be cleaned up after the Snapshot Debugger session is completed and the application pool is restarted. For our pre-release, we also recommend using a virtual machine with at least 8 GB of RAM.

Try TTD now!

We are incredibly excited about how this preview feature can help you improve debugging in Azure, but this is only the beginning. Our team continues to develop and create additional TTD features that we plan to add in upcoming releases of Visual Studio.

We look forward to your feedback!

Also popular now: