Several debugging techniques that must be mastered under Windows vs development

Code debugging is very important, sometimes the development time is not long, but most of the time is spent on debugging code, and we look for bugs, do not know how to debug is impossible task. Here are a few of the most basic debugging methods, although basic, but can definitely cover most of the development situation. To advanced, that may be windebug such a professional debugging tools. Of course, the reason for writing this article is that I found this information before, many people's articles are copy, and the method is a break point, this is the development of the work is simply nonsense. There is also a windebug. If you can introduce some practical, it is just. A large section of the introduction of windebug inside the command, there is no actual combat projects, there is no real useful things, so I have my current grasp of a little "open secret" to write, hope to help everyone. The spirit of the Internet, is to share Ah!

**************************************************************************************

1> Needless to say, the most common method is to break the point, and then single-step debugging to check whether your value is normal, the value is normal to say that there is no problem before running, then continue to go down, so that your range is getting smaller, can pinpoint the accident place. Break point is very convenient, at the front of the code, there is one, and then disappeared. Here are some quick commands, the first three are what I use, and the latter are not used at the moment.

F5: The debug State runs the program, and the program executes to a breakpoint where it will stop

F10: Stepping through the program

F11 and F10: The difference is that if the current execution statement is a function call, it will go inside the function

F9: Break breakpoint at the line where the current cursor is located, or cancel breakpoint if the current line already has a breakpoint

CTRL+SHIFT+F9: Remove all Breakpoints
CTRL+F10: Run to the cursor in the row
Shift+f11: Jump out of the current function

There may be a lot of people here who are wondering, does this seem useless? What I want to say here is a little trick. Is that the VS compiler will optimize our code, when you write the code after compiling, debugging sometimes will find some value is not normal (theoretically certainly normal), or obviously came here, the result breakpoint ran to another place. This is because vs has optimized the code, such as you int a = 1, but after that the value of a may not be used afterwards, then you may not be able to go to this place or the value of a to show an exception when you debug. This is very inconvenient for us to debug the code. Therefore, we use breakpoints debugging, if found inaccurate, first off the VS optimization, and so on after debugging, then restore. Close the optimized place on. Right-click Project Properties->c/c++->optimization, here are two places, one is optimization select disabled, there is favor Size or speed select neither. It's much easier to debug the code.

*********************************************************************************

2> consider such a situation. You packed a program for testing and then something went wrong. You don't know where the problem is. If you have to debug the source code in the compiler, there is no idea, the best way is of course debugging packaged programs AH. this time can be attached to the process with VS attach to process, there is a premise that this EXE must be your current code compiled and not modified, so as to attach success, otherwise it can not be captured, because the PDB is different, This self-check information. This example can not be very good, because we can completely re-debug the compiler, the example is a bit farfetched. Well, now look at such an example. If your program uses a lot of DLLs (your own project compiled DLL), and then you have a DLL problem, you only need to modify the DLL, modified, you want to see the correct changes. But the whole program needs to be re-packaged, and the process is time-consuming and cumbersome, and if the changes are not correct, you have to continue. Is there any way to use the current program to debug it? The answer is that you can replace the modified DLL with the DLL in the previously packaged program, run the program, and then place a breakpoint in the DLL code, and attach can debug it. This saves time and effort. The key to the operation of this technique is that the debug program or DLL must be consistent with your project, and if you modify the source code after compiling it, you cannot attch the success.

*****************************************************************************************

3> is now considering a variant of the above. If some of your operations are fast, that is, when you use the VS

*****************************************************************************************

Here are some of the debugging techniques I've mastered, but most of the code is no problem with these steps. If you are debugging a program that has no source code, then you have to use Windebug as a powerful tool, of course, I do not currently. After a good debugging will continue to put up.

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Several debugging techniques that must be mastered under Windows vs development