Common debugging methods of VC

Objective

VS is a very powerful IDE, so mastering Vsvc's common approach will make it easier to find problems and solve problems.

Directory

Common debugging methods of VSVC

Objective

1. Watch window to view pseudo-variables

2. View a sequence of values pointed to by the pointer

3. Memory Leak Lookup

4. Debug Release version

5. Remote Debugging

6. Function breakpoints

7. Data breakpoints.

8. Code Execution time

9. Formatting data

10. Formatting memory

1. Watch Window view pseudo variables

As described by MSDN, a pseudo-variable is a term used to view specific information. For example, when the calling API fails, you can use GetLastError to get the corresponding error code. However, many times it is not possible to modify the code at any time to view the current error code. At this point, you can quickly see the current error code in the Watch window with a pseudo-variable.

Some of the common pseudo-variables are:

• $tid – The thread ID of the current thread

• $PID – Process ID
• $cmdline – Command-line string for attaching a process

• $user – Account information that runs in the program
• $registername – Displays the register contents of the specified register

• $err – Displays the error code for the most recent error

• $err, hr– displays the most recent error message

Note: @err, err can be used correctly.

Detailed reference: https://msdn.microsoft.com/en-us/library/ms164891.aspx

1. View a sequence of values pointed to by a pointer

For example, there are 1 buff pointers of type int Pnbuff, and we want to see a series of values for it. Most of the time, people use the Memory window to view the entire piece of data. The int type is very inconvenient to view every 4 bytes. If you can view an array, it is very convenient to see the Watch window as it expands.

If you work in 1 large arrays that expand in watch (at least hundreds of elements, but may be less) then it will be difficult to find elements of a particular range. Because you have to scroll a lot. But if the array is allocated on the heap, you can't even expand its elements in the Watch window. Here are 1 solutions to that problem. You can apply the term (array + <offset>), <count> to see a specific range <count> start at <offset> location (the source array of your real objects). If you want to see all the arrays, you can simply use the Rray, <count>.

If your array is on a heap, then you can expand it in the Watch window, but to see 1 specific ranges, you have to use a slightly different syntax: ((t*) array + <offset>), <count> (Note that this syntax is also valid for multidimensional arrays on the heap). In this case, T is the type of the element of this array.

If you work under MFC and use the "array" container from it, like Carray,cdwordarray,cstringarray, and so on. You will certainly be able to apply the same filter, except that you must look at the member variable m_pdata of the array, which is the real cache that owns the data.

1. Memory Leak Lookup

VS at debug end exit, if there is a memory leak, the Output window will display the corresponding information, many of which will directly indicate the location of the memory is not freed, but sometimes it is not directly pointed out, this time need some other way to solve.

For example, the Output window information is as follows:

Dumping objects

D:\marius\vc++\debuggingdemos\debuggingdemos.cpp (103): {341} normal block at 0x00f71f38, 8 bytes long.

Data: < > CD CD CD CD CD

Object dump complete.

Method one, {341} above means that the code allocates memory for the No. 341 time. If the code is not random, the number will not change. Then we can add _CrtSetBreakAlloc (341) at the very beginning of the current code module, which means the code will break at the No. 341 memory allocation and then find the specific code location through the Call Stack window.

Method Two, use third-party tools, such as visual Leak Detector. Download the installation, and then add # include <vld.h> in the module code that you think is most likely to cause a memory leak. If you have stdafx.h, #include <vld.h> can be placed directly in this file. Then compile, debug, run, exit, and then display the details of the memory leak in the Output window.

1. Debug Release version

Release version and debug version of the main difference, the former code compilation is optimized, and some of the initial temporary variables, memory and other values may be random, the latter is not done code optimization, and uninitialized temporary variable default assignment is 0xCCCCCCCC, The default is 0xCDCDCDCD if the memory is on the heap. Because of the difference between the two, it may cause debug to run normally, and release under the problem of running errors. This time it may be necessary to debug the release. The method is simple, just close the optimization under release and turn on the generation of debug information.

• C + + > Optimization > Optimization should be "Disabled (/od)"
• Linker > Debugging > Generate Debug Info should be "Yes (/debug)"

Detailed reference: https://msdn.microsoft.com/en-us/library/fsk896zz.aspx

1. Remote debugging

If you can use the print debugging information to solve the problem, try not to use remote debugging. Feel the remote debugging, always easy out of various problems. But sometimes you have to use remote debugging, so here's a quick introduction.

• Copy the debug program and the corresponding PDB file on the local computer to the remote computer, noting that the debug program corresponds to the PDB file and the local computer.
• Copy the Debugging Monitor in the VS directory to the remote computer. Open debugging Monitor as an administrator, set to no user access mode, and remember the name of the service.

• Open the local computer vs, click Tool\attach to Process, launch the following window, and in the qualifier, fill in the Debugging Monitor on the remote computer on the name of the service.

Detailed reference: https://msdn.microsoft.com/en-us/vstudio/aa569599.aspx

1. Function Breakpoint

Function breakpoint, we often use, the mouse moves to a line, press F9, that is, set the most common breakpoint. Breakpoints also have a lot of advanced features, proficiency, can let us debug more convenient.

• Conditional breakpoint, as long as it is an expression.

• The number of trigger breakpoints.

• Filter breakpoints.

1. Data breakpoint.

Breakpoints in addition to our usual function breakpoints, there is a data breakpoint. You can select New Data breakpoint in the upper-left corner of the Breakpoints window.

Data breakpoints can be used to find out where a variable has changed in complex code. In addition, it is convenient to use data breakpoints for crashes caused by memory overwrite. Memory coverage causes a crash, often caused by an important variable being affected. So I just have to find the important variables and monitor them with data breakpoints.

1. Code Execution time

There is a special @clk in the pseudo-variable, which displays the system clock time, in milliseconds, by default.

At the first breakpoint, put the @clk into the Watch window and value 0.

At the second breakpoint, the @clk corresponding value is the approximate execution time of the code between two breakpoints.

1. Formatting data

When you look at a variable in the watch or Quick Watch window, the value is displayed with the default predefined visualization. When it becomes a number, they are displayed using a ten-progress system of their type (shaping, floating point, double precision). But you can force this debugger to display these numbers with different types or different binaries or both.

To change the display by prefixing the variable:

• By against unsigned characters (also known as unsigned bytes)
• Wo for unsigned short shaping (also known as unsigned words)
• DW for unsigned long shaping (also known as unsigned double word)

Change the display by adding a suffix to the variable name:

• , d or, I for signed decimal
• , U for unsigned decimal
• , O for unsigned octal
• , x for lowercase hexadecimal or, X for uppercase hexadecimal

1. Formatting memory

In addition to formatting data, the debugger can display formatted memory values up to 64 bytes in the Watch window. You can use the following specifier to format data later in an expression (variable or memory address).

• Mb/m-BYTE
• Mw-word
• Md-dword
• Mq–8byte
• Ma–16byte

• Mu–2byte UNICODE Characters

1. Other

A piece of code into the dead loop, how quickly to find where it? Direct click to break all.

Application open exception, call DLL exception, use Dependens.exe.

Common debugging methods of VC