The intelligent tracing feature of Visual Studio 2010-intellitrace

The Visual Studio Ultimate version has a new feature IntelliTrace (Intelligent tracking), IntelliTrace is introduced to Visula Studio to speed up our right. NET application, it can quickly pass on the state of the program during execution and various kinds of information to help the developer to better debug the program and quickly discover the problem by tracking the preset events and methods and passing them to the debugging performer effectively. In fact, prior to Visual Studio 2010, Microsoft Visual Stuido had helped us to inherit the debugging tools, such as monitoring variables, viewing stacks, and so on, and allowing breakpoints to be set for Single-step debugging. All of this is good for developers to understand the state of the program in different execution and to detect whether it works according to the actual logic in advance, and more, we detect the problem by monitoring the program state after the breakpoint. The problem with this is that some logical errors can occur before the breakpoint is executed, and it is likely that some are untraceable. The developer must stop the current debugging, reset the breakpoint and start debugging, which often takes many times to find the correct location to set the breakpoint. IntelliTrace intelligently tracks and implements some of the debugging information and program status to developers, reducing the need for programmers to find the right breakpoints to track and monitor the state of the program's operation.

Visual Studio provides us with two ways to control the content source for which it collects information, one IntelliTrace events only, collecting data about intelligent tracking events and debugging interrupts; the other is IntelliTrace events and Call information, which collects various data on the entry and exit of a method invocation except for the IntelliTrace event. Let's take a look at how to set trace options for IntelliTrace in Visual Studio 2010.

Go to the tool--> option--> IntelliTrace. It is enabled by default, but only events are captured because capturing events is inexpensive. However, when you start tracking all of these invocation messages, the real value begins to appear. Every time you debug, IntelliTrace will bounce out and you can use this historic debugging tool when you debug dynamically. If I am there and have a breakpoint, but I want to back up and redesign this breakpoint, I can use IntelliTrace to complete this task.

Other people who use IntelliTrace to capture the debug process can send you records as well as. DLLs and PDBs files, and you can replay their progress. This process may go into the database (you don't have the database), it may be set in a way you can't replicate, it may be on a network 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 you can see the code as if it was being debugged on your own machine. This is good for the mysterious faults that are running normally on your machine and not running on other people's machines. It is also very good for multi-threaded situations, and when you go through the application, the software flaw disappears, but this software flaw appears again at normal speed.

By default, IntelliTrace only collects IntelliTrace-related events in order to keep the data collected less and has minimal performance impact. And when you choose to collect data for method calls, in addition to the increased space occupied by the data collected temporarily, the effect on performance is also greater. Although the details collected are different, there are two ways to collect some common data. For example, it always collects system information, loading and unloading events, thread start and end times, and so on when the collection process is first started. With the module and thread events, you can correctly update the information for the module and the Thread Debugging window. Also, in any mode, the data is collected at the debug breakpoint, and the collected base data types and objects are checked and reviewed in the debug, and their values are allowed to change.

In general, the IntelliTrace debugger is tailor-made for the program developers, through its unique "historical debugging" function, to provide developers with a backtracking retrospective process control function. For example, in the development of the program in 10 minutes before the occurrence of an exception, how to do, if in the past is generally through manual call Debug.Write statements, now do not have! Because this kind of historical debugging in many development tools is very similar, the VS2010 in the official version of the IntelliTrace, not only allows programmers to see the current state of the program, but also to check the events generated in some cases, and even isolate the application history of the point of failure. So, after you enable history debugging, the VS2010 official edition can capture the call stack and related variables, and we can "roll back" to 10 minutes or more before the program is saved, checking for various situations in which the program is abnormal or failing. Because, by default, the program saves only the critical types, and the developer can choose to record all parameters, objects, and global variables. Therefore, IntelliTrace will actively display the key events in the process of running the program, such as code exceptions, file access, debugging, and so on.

A better understanding of using the IntelliTrace debugging feature, you are recommending an article on MSDN Magazine IntelliTrace: Using IntelliTrace to debug your application, Justin Marks demonstrates how to use Visual Studio 2010 The IntelliTrace feature, available in the flagship edition, provides developers with a powerful new debugging tool to speed up debugging and gather the full execution history of the application, get deeper information, and quickly find bugs.