Recently I happened to have read an article by Ivan Shcherbakov titled 11 powerful Visual Studio debugging tips. This article only introduces some basic debugging skills about Visual Studio, but also some useful skills. I have compiled some Native Development debugging skills for Visual Studio (at least in VS 2008. (If you are working on hosted code, the debugger will have more features and articles about them in CodeProject). Below are some of my skills:
Exception interrupt | Break on Exception
Pseudo variables in the Watch window | Pseudo-variables in Watch Windows
View the heap object after the symbol crosses the border |
View array values
Avoid entering unnecessary functions
Start the debugger from the code | Launch the debugger from code
Print in Output window
Isolate Memory leakage
Debug Release | Debug the Release Build
Remote debugging
Tip 1: Abnormal interruption
Before handling a call, you can start the debugger to interrupt the exception, so that you can debug the program immediately after the exception occurs. The operation call stack helps you find out the root cause of the exception.
Vistual Studio allows you to specify the exception type or special exception you want to interrupt. Select the Debug> Exceptions dialog box. You can specify native (or hosted) Exceptions. In addition to some default Exceptions that come with the debugger, you can also add your own custom Exceptions.
The following is an example of Debugger interruption when an std: exception is thrown.
Read more:
- 1. How to interrupt when an exception is thrown
- 2. How to add new exceptions
Tip 2: pseudo variables in the Watch window
The Watch window or QuickWatch dialog box provides some specific variables (which can be recognized by the debugger), called pseudo variables. The document includes the following:
$ Tid -- ID of the thread of the current thread
$ Pid -- process ID
$ Cmdline ---- command line string for starting the program
$ User ---- account information of the running program
$ Registername -- display the contents of the register registername
In any case, the pseudo variables for the last error are very useful:
$ Err --- display the last error code
$ Err, hr-display the last error message
Read more: pseudo variables
Tip 3: view the heap object after the heap is exceeded
Sometimes, when the debugging symbol is out of bounds, you still want to view the object value. In this case, the variables in the watch window are disabled and cannot be viewed (or updated ), although the object still exists. If you know the object address, you can continue to fully observe it. You can convert an address to a pointer of this object type and put it in the watch window.
In the following example, after a single step jumps out of do_foo (), _ foo cannot be accessed again. However, after converting its address to foo *, you can continue to observe this object.
Tip 4: view the array value
If you are operating on a large array (we suppose there are at least several hundred elements, but there may be fewer), expand the array in the Watch window, it is very troublesome to search for elements in a specific range because you have to keep rolling. if the array is allocated to the heap, you cannot expand the array element in the watch window. there is a solution to this. You can use (array + <offset>) and <count> to view the <count> element of a specific range starting from the <offset> position (of course, the array here is your actual object ). To view the entire array, you can simply use array, <count>.
If your array is on the stack, you can expand it in the watch window, but to view the value of a specific range, the usage is slightly different :( (T *) array + <offset>), <count> (note that this usage is also effective for multi-dimensional arrays on the stack ). In this case, T is the type of an exponential group element.
If you are using MFC and use the 'array' container, such as CArray, CDWordArray, and CStringArray. Of course you can use the same filtering method. In addition, you must view the m_pData Member of the array, which is the real cache for storing data.
Tip 5: avoid entering unnecessary functions
Many times, when debugging code, you may enter the functions you want to skip, such as constructors, value assignment operations, or other functions. The most disturbing problem is the CString constructor. The following is an example. When you are going to execute the take_a_string () function in a single step, you first enter the CString constructor.
Void take_a_string (CString const & text) {} void test_string () {take_a_string (_ T ("sample "));}
Fortunately, you can tell the debugger which methods, classes, or namespaces to skip. The method for implementing it has also changed. Back to the day when VS6 was used, which is usually specified through the autoexp. dat file. Changed Vistual Studio 2002 to use registry settings. To skip some functions, you need to add some values in the Registry (details are as follows ):
The actual location depends on the Vistual Studio version you are using and the operating system platform (x86 or x64, because the Registry can only be viewed under 64-bit Windows). The value is a number, indicating the priority of the rule; the greater the number, the higher the priority. Value data is the REG_SZ value of a regular expression, used to specify how to filter and execute.
To avoid entering any CString method, I added the following rules:
With this, the debugger skips the CString constructor even if you forcibly enter take_a_string () in the previous example.
Read more:
- How to avoid entering functions using the Visual C ++ Debugger
- Use AutoExp. dat to adjust the debugger
Tip 6: Start the debugger Launch the debugger from code
You may rarely need to Attach the debugger to a program, but you cannot do this in the Attach window (it may be because the interruption occurs too fast and not captured ), you cannot start a program in the debugger at the beginning. You can generate an interrupt in the program to give the debugger a chance to append it by calling the internal _ degbugbreak.
Copy codeThe Code is as follows:
Void break_for_debugging (){
_ Debugbreak ();
}
There are actually other methods to do this, such as triggering interrupt 3, but this is only applicable to x86 platforms (C ++ 64-bit does not support ASM ). There is also the DebugBreak () function, but it is not easy to use, so we recommend using internal methods here.
Copy codeThe Code is as follows: _ asm int 3;
The program stops running when running the internal method, and you have the opportunity to attach the debugger to the process.
Read more:
- Internal method_debugbreak
- You cannot do without setting breakpoints and assertions at any time.
- Visual Studio 20005/2008 debugging, Part 4: Set code for the debugger
Tip 7: print in the output window
You can call DebugOutputString to display a specific piece of text in the output window of the debugger. If no debugger is attached, this function does not do anything.
Read more:
- Function OutputDebugString
- Call mechanism of the function OutputDebugString
Tip 8: isolate memory leakage
Memory leakage is an important issue in native development. It is a serious challenge to detect memory leakage, especially in large projects. Vistual Studio provides reports to detect memory leaks, and other applications (free or commercial) can also help you detect memory leaks. in some cases, you can use the debugger to interrupt some memory allocation that will eventually cause leakage. However, you must find a reproducible Allocation Number (though not that easy ). If this can be done, the debugger will interrupt the execution of the program.
Let's take a look at the following code. Eight bytes are allocated, but the allocated memory has never been released. Visual Studio provides a report on the objects that cause memory leakage. When you run the report several times, you will find that it is always the same allocation number (341 ).
Copy codeThe Code is as follows:
Void leak_some_memory ()
{
Char * buffer = new char [8];
}
Dumping objects->
D: \ marius \ vc ++ \ debuggingdemos. cpp (103): {341} normal block at 0x00F71F38, 8 bytes long.
Data: <> CD
The steps for interruption at a specific (reproducible) location are as follows:
Make sure you have enough reporting mode for Memory leakage (refer to using CRT library to detect memory leakage)
Run the program multiple times until you can find a reproducible allocation number in the memory leak report after the program runs, for example (341) in the previous example)
Set a breakpoint at the beginning of the program so that you can interrupt it as soon as possible.
When the initial interruption occurs, the Name column of the watch window will display: {, msvcr90d. dll} _ crtBreakAlloc, and the position number you want to search in the Value column.
Continue debugging (F5)
The execution of the program stops at the specified position. You can use the call stack to find the code triggered by this position.
Follow these steps to identify the cause of Memory leakage by using the allocated number (341) in the previous example.
Tip 9: debug the release
Debugging and publishing are two different purposes. Debugging configuration is used for development, and publishing configuration, as the name suggests, is used as the final version of the program, because it must strictly follow the quality requirements of publishing, this configuration includes the optimization part and debugging version interrupt debugging settings. In addition, sometimes you need to debug the release version just like debugging the version. To achieve this, you need to make some changes in the configuration. However, in this case, you are no longer debugging the release version, but debugging and publishing a hybrid version.
You should also do the following:
Set C/C ++> General> Debug Information Format to "Program Database (/Zi )"
Set C/C ++> Optimization to "Disabld (/Od )"
Set Linker> Debugging> Generate Debug Info to "Yes/(DEBUG )"
:
Read more: How to debug the release
Tip 10: remote debugging
Another important debugging task is remote debugging. This is a big topic and has been mentioned many times. Here I just give a brief summary:
You need to install remote debugging monitoring on a remote machine
Remote debugging monitoring must run as an administrator and the user must belong to the Administrator group.
When you run monitoring, a new service is enabled. The service name must be the value of the Qualifier combo box in the Attach to Progress window of Visual Studio.
- The firewall on the remote and local machines must allow communication between Visual Studio and remote debugging monitoring.
- To debug a PDB file, the key is to allow Visual Studio to automatically load them. The following conditions must be met:
1) Local PDB files must be available (put a corresponding module in the same path of the remote machine ).
2) The hosted PDB culture on remote machines must be available.
Remote debugging monitoring download:
- Visual Studio 2008 Service Pack 1 Remote Debugger
- Microsoft Visual Studio 2010 Remote Debugger
Read more:
- Set remote debugging
- How to run remote debugging monitoring
- Load debugging symbols during remote debugging: local hosting
- PDB file: developer notice
- Visual Studio remote debugging and PDB files
- How to specify the symbol position and loading Behavior
Conclusion
Ivan Shcherbakov's article and the debugging skills I mentioned in this article are essential in most debugging problems. To learn more about debugging skills, we recommend that you read the additional information provided in this Article.
Original article: Marius Bancila Translation: bole online-bole online readers
Http://blog.jobbole.com/45249/.
