Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the debugging skills of Visual Studio native development". In daily operation, I believe many people have doubts about what debugging skills of Visual Studio native development. The editor consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the questions of "what debugging skills of Visual Studio native development". Next, please follow the editor to study!

Tip 11: data breakpoints

When the memory location of the data changes, the debugger will break. However, this is the only data breakpoint where it is possible to create hardware like 4 at a time. Data breakpoints can only be added during compilation, either through the menu (compile > New breakpoints > New data breakpoints) or through the breakpoint window.

You can use a memory address or address expression. Even if you can see the two values on the stack, I think this feature is usually useful when the values on the heap are changed. This is a great help in identifying memory corruption.

In the following example, the value of the pointer has been changed to the value of the object to which it points. To find out where the change was made, I set a breakpoint at the location where the pointer value is stored, such as & ptr (note that this occurs after the pointer is initialized). When the data changes, it means that someone has changed the value of the pointer, the debugger terminates, and then you can find out which code caused the change.

Tip 12: rename threads

When you debug a multithreaded application, the Threads window shows which threads have been created, as well as the current thread. The more threads you have, the harder it is to find the thread you are looking for (especially when the same program is executed by multiple threads at the same time, you don't know which thread instance is currently executing)

The debugger allows you to rename threads. Right-click a thread and rename it.

You can also name a thread programmatically, although this is a bit tricky and must be done after the thread starts, otherwise the debugger will reinitialize it with its default naming convention, and the following function shows how to define and use a thread.

Typedef struct tagTHREADNAME_INFO {DWORD dwType; / / must be a two-byte length LPCSTR szName; / / pointer to a named (same address space) DWORD dwThreadID; / / thread ID (- 1 calling thread) DWORD dwFlags; / / reserved, in most cases 0} THREADNAME_INFO; void SetThreadName (DWORD dwThreadID, LPCSTR szThreadName) {THREADNAME_INFO info; info.dwType = 0x1000; info.szName = szThreadName; info.dwThreadID = dwThreadID Info.dwFlags = 0; _ _ try {RaiseException (0x406D1388, 0, sizeof (info) / sizeof (DWORD), (DWORD*) & info);} _ except (EXCEPTION_CONTINUE_EXECUTION) {}}

Tip 13: specify thread to set breakpoint

Another useful technique for multithreaded applications is to set breakpoints on specified threads, processes, or even computers. You can use the breakpoint's Filer command to do this.

The debugger allows you to use different combinations of thread name, thread ID, process name, process ID, and machine name (using AND, OR, NOT connections). Knowing how to set the thread name also makes this filtering technique easier to operate.

Tip 14: (inaccurate) timing execution

In my previous article, I mentioned using pseudo variables in the Watch window. One of the things that is not mentioned is @ clk, which displays the value of a counter to get the approximate time required for code execution between two breakpoints, in milliseconds (ms). However, this method cannot be used to configure program execution. You should use Visual Studio Profiler or performance timers to complete these configurations.

Reset the timer by adding @ clk=0 to the Watch window or the Immediate window. Therefore, if you need to calculate the time required for the last piece of code to execute, do the following:

Set a breakpoint at the beginning of the code block

Set a breakpoint at the end of the code block

Add @ clk to the Watch window

When the first breakpoint is triggered, enter @ clk=0 in the Intermediate window

Run the program until you encounter a breakpoint at the end of the code block and view the value of @ clk in the Watch window

Note that there is a trick on the Internet that you need to add two expressions to the Watch window: @ clk and @ clk=0, which is said to reset the timer at the location where the breakpoint is executed each time. This technique can only be used in earlier versions of Visual Studio, but not in higher versions of VS, such as VS2005 (the author has tested it, and vs2005 does not support this technique) and later.

Tip 15: format numbers

When you use the Watch or Quick Watch window to view variables, these values are displayed in the default predefined visual format. When variables are numeric, the display forms are based on their type (int, float, double) and are displayed in decimal system. However, you can set the debugger to use different types for displaying numbers, or use different bases.

To change the variable display type, you can add the following prefix to the variable:

By-unsigned char (unsigned byte)

Wo-unsigned short (unsigned word)

Dw-unsigned long (unsigned double word)

To change the base in which the variable is displayed, you can add the following prefix to the variable:

D or I-signed decimal number

U-unsigned decimal number

O-unsigned octal number

X-lowercase hexadecimal number

X-uppercase hexadecimal number

Tip 16: format memory data

In addition to numbers, debugger can also display formatted memory data in a Watch window, up to 64 bytes in length. You can format the data by adding the following suffix to the expression (variable or memory address):

Mb or m-16 bytes of data displayed in hexadecimal, followed by 16 ASCII characters

Mw-8 character (WORD, usually 1 WORD = 2 BYTE) data

Md-4 double word (DWORD, usually 1 DWORD = 4 BYTE) data

Mq-2 four-word (Quad WORD) data

Ma-64 ASCII characters

Mu-2 byte UNICODE character

Tip 17: pause at the system DLL call

Sometimes it is useful to pause when a function of DLL is called, especially the system DLL (such as kernel32.dll, user32.dll). Implementing this pause requires the use of the context operator provided by the native debugger. You can set the breakpoint location, variable name, or expression:

{[function], [source code], [module]} breakpoint location

{[function], [source code], [module]} variable name

{[function], [source code], [module]} expression

Curly braces can be any combination of function names, source code, and modules, but commas cannot be omitted.

For example, if we need to pause when the CreateThread function is called. This function is derived from kernel32.dll, so the context operator should look like this: {, kernel32.dll} CreateThread. However, this doesn't work, because the operator requires a CreateThread-decorated name. You can use DBH.exe to get the decorated name of a specific function (compiled by the compiler).

Here is how to get the decorated name of CreateThread:

C:\ Program Files (x86)\ Debugging Tools for Windows (x86) > dbh.exe-s:srv*C:\ Symbols* http://msdl.microsoft.com/Download/Symbols-d C:\ Windows\ SysWOW64\ kernel32.dll enum * CreateThread*Symbol Search Path: srv*C:\ Symbols* http://msdl.microsoft.com/Download/Symbols index address name 1 10b4f65: _ BaseCreateThreadPoolThread@12 2 102e6b7: _ CreateThreadpoolWork@12 3 103234c: _ CreateThreadpoolStub@ 4 4 1011ea8: _ CreateThreadStub@24 5 1019d40: _ NtWow64CsrBasepCreateThread@12 6 1019464:? @ 0 d 102e6e3: _ CreateThreadpoolTimerStub@12 e 1038ff0: _ CreateThreadpoolIo@16 f 102e766: _ CreateThreadpoolWait@12 10 102e6aa: _ CreateThreadpoolWorkStub@12 11 1032359: _ CreateThreadpool@4

It looks like the real name is _ CreateThreadStub@24. So we can create a breakpoint, {, kernel32.dll} _ CreateThreadStub@24.

Run the program and directly ignore the message that there is no relevant source code at the breakpoint when a pause is encountered.

Use the call stack window to view the code that calls this function.

Tip 18: load symbols

When you debug a program, the call stack window may not display the entire call stack, ignoring system DLL (such as kernel32.dll, user32.dll) information.

By loading the symbolic information of these DLL, you can get all the call stack information, and in the call stack window, use the context menu (right-click menu) to set this effect directly. You can download these symbols from predefined symbol paths or from Microsoft's symbol server (for system DLL). After these symbols are downloaded and imported into debugger, the call stack is updated as follows:

These symbols can also be imported from the Module window.

Once loaded, the symbols are saved in the cache and can be configured in Tools > Options > Debugging > Symbols.

Tip 19: report memory leaks in MFC

If you want to monitor memory leaks in MFC applications, you can use the macro debug _ NEW to redefine the new operator, a modified version of the new operator that records the file name and line number of memory allocated. The DEBUG_NEW built in the Release version parses to the original new operator.

Mina contains the following preprocessing instructions in the source code generated by the MFC wizard after # include:

# ifdef _ DEBUG#define new DEBUG_NEW#endif

The above code is how to redefine the new operator.

Many STL header files are not compatible with the new operator defined here. If you include an equal header file after redefining the operator new, you will have the following error (as an example):

1 > c:\ program files (x86)\ microsoft visual studio 9.0\ vc\ include\ xmemory (43): error C2665: 'operator new': none of the 5 overloads could convert all the argument types1 > c:\ program files\ microsoft visual studio 9.0\ vc\ include\ new.h (85): could be' void * operator new (size_t) Const std::nothrow_t &) throw ()'1 > c:\ program files\ microsoft visual studio 9.0\ vc\ include\ new.h (93): or 'void * operator new (size_t,void *)' 1 > while trying to match the argument list'(const char [70], int)'1 > c:\ program files (x86)\ microsoft visual studio 9.0\ vc\ include\ xmemory (145): see reference to function template instantiation'_ Ty * std::_Allocate (size_t _ Ty *) 'being compiled1 > with1 > [1 > _ Ty=char1 >] 1 > c:\ program files (x86)\ microsoft visual studio 9.0\ vc\ include\ xmemory (144C): while compiling class template member function' char * std::allocator::allocate (std::allocator::size_type)'1 > with1 > [1 > _ Ty=char1 >] 1 > c:\ program files (x86)\ microsoft visual studio 9.0\ vc\ include\ xstring (2216): See reference to class template instantiation 'std::allocator' being compiled1 > with1 > [1 > _ Ty=char1 >]

The workaround is to use DEBUG_NEW to redefine the new operator after including these STL files.

Tip 20: debug ATL

When you develop ATL COM components, you can view the QueryInterface, AddRef, and Release calls of the COM objects you develop in debugger. The production of these calls is not supported by default, you need to define two macros in the preprocessing definition or precompiled header file. After these two macros are defined, calls to these functions are displayed in the Output window.

These two macros are:

_ ATL_DEBUG_QI, which displays the name of each queried interface. Must be defined before the atlcom.h header file is included.

_ ATL_DEBUG_INTERFACES, which displays the number of references to the current interface as well as class name, interface name and other information whenever AddRef or Release is called. Must be defined before the atlbase.h is included.

At this point, the study of "what are the debugging skills of Visual Studio native development" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.