Visual Studio Debugging Breakpoints Advanced

In the previous article, Visual Studio debugging breakpoints in the basic article describes what is a breakpoint, INT is an Intel series CPU instruction, can let the program produce an interrupt or an exception. If there is an interrupt or an exception occurs in the program, the CPU interrupts the execution of the program, and a part called IDT looks for a routine (Handler) to handle the interrupt (or exception). IDT is initialized when the operating system is started, and as for the details of IDT, such as what is IDT, how to write an IDT routine, how to initialize IDT, to search for some information online.

In short, here we just need to know that the CPU in the execution of the program instruction process, encountered an int 3 interrupt program execution, the CPU then went to the IDT table to find the processing breakpoint of the routine entrance. The thing to do with this routine is:

1. First look at the machine is not installed a debugger-remember, this step is important, the reason is important in the article will be introduced.

2. If there is no debugger installed in the machine, then the operating system will terminate the execution of the program.

3. Otherwise the operating system starts the debugger and the debugger is attached to the process.

4. In this way, we can check the value of the internal variables of the program inside the debugger.

The int 3 (or DebugBreak (), or debugger.break ()) instruction in the previous article is our own hard-coded inside the code, so in Visual Studio, in the corresponding line of code, a little red ball appears. That is, Visual Studio dynamically adds an int 3 directive somewhere in the program instruction set. Now that's the question, how does Visual studio find the correct position to insert the Int 3 directive in the program?

Or more specifically, we set breakpoints in the source code (text file), and Visual studio needs to translate the line of code into the location in the program's instruction set. Visual Studio needs to translate because the usual line of C + + or C # code will correspond to several lines of assembly instructions.

As a result, Visual Studio needs an extra file to perform the translation process, and this additional file is called the Debug symbol file (Symbols), which is generated by the compiler. Visual Studio family of compilers, whether C #, VB. NET or C + + compiler will generate this debug symbol file,. pdb file. So if you take a moment to look at the Debug folder, you'll find this file.

So let's take a look at the various breakpoints supported by Visual Studio and explain how the various breakpoints are implemented

Conditional breakpoint

First we look at how to set conditional breakpoints, conditional breakpoints have two, one is set according to the number of times triggered, and the other is based on a preset condition to set.

Set according to the number of triggers

For example, you have a loop, loop 1000 times, you know that there is a bug is always 500 times before the appearance, so you certainly want to set a breakpoint in the loop, but the previous 500 times will not trigger this breakpoint, or the continuous press 500 times F5 is indeed not an easy errand.

Set according to preset conditions

If you already know that some conditions may be causing a bug, then setting it according to the conditions is the best fit. As shown in the following:

In the breakpoint condition (Breakpoint Condition) dialog box, you only need to enter a normal C #, C + +, or vb.net statement (of course, the syntax is consistent with the source code syntax in your project), the requirement of this statement is that you must return a bool value- Otherwise, it's not a condition.

The third one is the breakpoint filter, and when you right-click on the breakpoint, you will have a "filter" menu, which allows you to restrict the breakpoint from being set to a specific thread. Here I will not talk about, if you are interested, you can write a multi-threaded or multi-process program to try this function.

Once you know the principle of breakpoints, understanding conditional breakpoints should not be a problem.

Monitoring breakpoints (watching point)

Sometimes you might want to look at the values of some variables inside the program, but you don't want to interrupt the execution of the program. For example, you are debugging a network protocol stack, a program may be receiving packets, you want to look at the format of the packet, but if the execution of the interrupt program, will cause subsequent packet loss.

Therefore, our general practice is to add some log code in the source code, so that the values of some variables can be recorded for subsequent analysis. Adding these log codes to the source code is a good idea if the logs are needed after the product is released, but what if you just want to take a look at the values of some variables?

At this point, it is useful to monitor breakpoints, and Visual studio's monitoring breakpoints allow you to print the values of some variables in the debugger window without modifying the source code of the program.

Demonstrates the use of a monitoring breakpoint:

Set the steps to monitor breakpoints, or note it:

1. Set a normal breakpoint

2. Right-click on the breakpoint you just set and select "When hit ..." in the popup menu.

3. Tick the first "Print a message" check box, enter a string of text, by default, the text you enter will be printed directly into the Debug Output window. Apart from:

A. A few keywords that begin with the $ sign. For example, $function will be replaced with the function name where the breakpoint is located. Some other keywords are described in detail in the "when breakpoints are hit" window.

B. Use a variable name that is enclosed by curly braces {}, so that the string is replaced with the value of the variable.

Here is the effect of monitoring breakpoints, and note that you can only view the results in the Output window of Visual Studio.

The benefit of monitoring breakpoints relative to logging is that you do not need to change the source code and recompile the code. In fact, Visual Studio implements the principle of monitoring breakpoints is simple, is to insert a normal breakpoint, the breakpoint is triggered after processing and printing in the "When the breakpoints is the" window output expression, and finally automatically recover the execution of the program.

Breakpoints in Visual studio debugging step-by-step article