Visual Studio Debugging Breakpoints Basics

original link Address: http://www.cnblogs.com/killmyday/archive/2009/09/26/1574311.html

I have asked a lot of people, how do you usually debug your program?

F9, F5, F11, F ...

There are many books and articles that describe how to use Visual Studio to write WinForm, ASP. NET, it is important to know how to write, but I think programmers may only spend 30% of their time writing code, and most of the rest of the time is in debugging the program. See a lot of people on the Internet to introduce the usage of WinDbg, but did not see several articles that explain the use of Visual Studio debugging. WinDbg is strong, but the problem is that its learning curve is too steep, and a lot of debugging does not need to use WinDbg to debug (of course, not that I will not WinDbg debugging-this is the future of the Debug series will say), why not use our most familiar with the visual Studio to do the debugging?

debugging, nothing more than to see the program at run time, the internal state, such as the value of some variables, look at the path of the program call and so on. Of course the most direct way is to directly interrupt the execution of the program, with the debugger to check the situation of the program. So F9, F5, F10, F11 ...

So let's just say what is a breakpoint, what is a breakpoint? Not F9, nor the little red ball, in the Intel series of CPUs (including AMD-produced CPUs), it is actually a special instruction-int 3. When the CPU executes the instruction set of the program, it interrupts the execution of the program whenever it encounters this instruction (of course, the CPU notifies the operating system, then ...). And then...... Then ..., the implementation mechanism of the breakpoint I will explain in a future article, now we just know that the int 3 instruction will interrupt the execution of the program OK? ）。

Of course, we need to use the facts to prove my above, so the following program compiled and executed, point "Yes", point "break", on the right, the program is interrupted, I believe you can see:

#include <stdio.h>void  main () {       printf ("before breakpoint"N " ); __asm       {int3       }       printf ("before breakpoint" n"); }

Compile method:

1. Open the Visual Studio 2008[2005] command Prompt (Visual Studio 2008[2005) command line in the Start menu.

2. Enter the path to the folder that holds the C source code (INT3.C) above.

3. Execute the Compile command (because my machine is Windows 7 RC + Visual Studio + x64 CPU, direct compilation has a little problem, if your machine is not my above configuration, you can try to perform cl/zi int3.c)

CL/ZI/C int3.c

4. Execute the link command (you can skip this step if you have executed the command directly cl/zi int3.c).

Link/libpath: "C:" program Files "Microsoft SDKs" Windows "v6.0a" Lib "int3.obj

5. Run the Int3.exe of the output.

At this point you should see Visual Studio bounce out and then break above int 3 on the source line, indicating that we have successfully interrupted the CPU to int3.exe the execution of the program.

Tip : If you do not see the Visual Studio window pop-up when you execute Int3.exe, click "Tools"-"options" in the Visual Studio menu item, and then in the " Options window, select Debugging (Debug)-Just-in-time (Instant Debug), and then tick the Native (native) option. As shown in the following:

"In summary, the breakpoint is int 3 This command triggered!" (A mathematical proof of childhood) ".

What functions are derived from the Int 3 directive, which is, of course, on the Intel series CPU:

To be Continued ...

Visual Studio Debugging Breakpoints Basics