Visual Studio 2010 Ultimate version has a new feature IntelliTrace (intelligent tracing). IntelliTrace was introduced into Visual Studio to speed up our debugging of .NET applications. It tracks preset events and methods during the running process and It is effectively passed to the debugging executor, thereby quickly transmitting the status and various information of the program during execution to help developers better debug the program and quickly find problems. In fact, before Visual Studio 2010, Microsoft Visual Stuido has helped us inherit debugging tools very well, such as monitoring variables, viewing stacks, etc., and allowing setting breakpoints for single-step debugging, etc. All of these are very helpful for developers to understand the status of the program in different execution processes and detect whether it is running according to the actual logic in advance. And more, we can find the problem by monitoring the program status after breakpoints. . The problem with this is that some logical errors may occur before the breakpoint is executed, and they may not be traceable. Developers must stop the current debugging, reset the breakpoint and start debugging, and this experimental process often takes many times to find the correct location to set the breakpoint. IntelliTrace intelligently automatically tracks and displays some debugging information and program status to developers, thereby reducing the need for programmers to find appropriate breakpoints to track and monitor the running status of the program.
Visual Studio provides us with two ways to control the content source of information it collects. One is IntelliTrace events only, which only collects data related to intelligent tracing events and debugging interrupts; the other is IntelliTrace events and call information, which will collect data in addition to IntelliTrace Various data on the entry and exit of a method call outside of events. Let's take a look at how to set IntelliTrace's tracing options in Visual Studio 2010.
Go to Tools-->Options-->IntelliTrace. It is enabled by default, however, only captures events because capturing events is cheap. However, when you start tracking all of these call information, the real value starts to show. Every time you debug, IntelliTrace will pop up. You can use this historical debugging tool during dynamic debugging. Say I'm there and I have a breakpoint, but, I want to back up and redesign this breakpoint, I can use IntelliTrace to accomplish this task.
Others who have captured their debugging processes using IntelliTrace can send you the recordings and .dlls and pdbs files, and you can replay their processes. The process might go into the database (you don't have the database), it might be set up in a way that you can't copy, it might be on a network that you can't reach, but, you don't have to worry because you have the records and the .dlls and pdbs files that you can replay.
Of course, it's better to have the source code, because then you can see the code as if you were debugging it on your own machine. This is great for those mysterious glitches that work fine on your machine but not on other people's machines. It's also very good for multi-threaded situations, and as you go through the application, the software glitch disappears, but when running at normal speed, the software glitch appears again.
By default, IntelliTrace only collects IntelliTrace related events. This is to keep the data collected small and the impact on performance is minimal. When you choose to also collect data on method calls, in addition to the increase in the space occupied by the temporarily collected data, the impact on performance is also greater. Although the details collected vary, both methods collect some common data. For example, it will always collect system information when the collection process is started for the first time, module loading and unloading events, thread start and end times, etc. As module and thread events occur, module and thread debugging window information can be updated correctly. In addition, in any mode, data will also be collected at debugging breakpoints, and the collected basic data types and objects will be inspected and reviewed during debugging, and their values will be allowed to be changed.
Generally speaking, the IntelliTrace debugger is tailor-made for program developers. Through its unique historical debugging function, it provides developers with a regret traceability process control function. For example, what should I do if an exception occurred 10 minutes ago in the program during development? If in the past, it was usually done by manually calling the Debug.Write statement, now there is no need! Because the historical debugging functions in many development tools are very similar, through IntelliTrace in the official version of VS2010, programmers can not only see the current status of the program, but also check events generated under certain circumstances, and even Isolate points of failure in application history. Therefore, after enabling historical debugging, the official version of VS2010 can capture the call stack and related variables. We can go back to 10 minutes or more before the program was saved to check various situations when exceptions and failures occur in the program. Because by default the program only saves key types, the developer can choose to log all parameters, objects and global variables. Therefore, IntelliTrace will actively display key events during program running, such as code exceptions, file access, real-time debugging, etc.