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

This article introduces the relevant knowledge of "what are the debugging skills of Visual Studio native development". In the operation of actual cases, many people will encounter such a dilemma, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Tip 1: abnormal interruption

Before processing is called, when an exception occurs, you can start the debugger to interrupt, allowing you to debug the program immediately after the exception occurs. The operation call stack makes it easy for you to find the root cause of the exception.

Vistual Studio allows you to specify the type of exception or special exception you want to interrupt. Select the menu Debug > Exceptions pop-up dialog box, you can specify native (or managed) 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 a debugger break when a std::exception exception is thrown.

Read more:

1. How to break when an exception is thrown

2. How to add new exceptions

Pseudo variables in the trick 2:Watch window

Watch windows or QuickWatch dialogs provide specific (debugger-recognizable) variables called pseudo variables. The document contains the following:

$tid-- Thread ID of the current thread

$pid-- process ID

Command line string for the $cmdline---- launcher

Account information of $user---- running program

$registername-- displays the contents of the register registername

In any case, the pseudo variable about the last error is very useful:

$err--- displays the error code of the last error

$err,hr- displays the error message of the last error

Read more: pseudo variables

Tip 3: view heap objects after matching out of bounds

Sometimes, when you want to see the value of an object after the debug symbol is out of bounds, the variables in the watch window are disabled and can no longer be viewed (or updated), although the object still exists. If you know the address of the object, you can continue to observe it fully. You can convert the address to a pointer of that object type and place it in the watch window.

In the following example, after stepping out of do_foo (), _ foo can no longer be accessed. However, after translating its address to foo*, you can continue to observe the object.

Tip 4: view the values of the array

If you are working on a large array (let's assume there are at least a few hundred elements, but maybe less), expanding the array in the Watch window to find some specific range of elements is troublesome because you have to keep scrolling. If the array is allocated on the heap, you can't even expand the array elements in the watch window. There is a solution to this. You can use (array+) to view a specific range of elements starting from the location (of course, the array here is your actual object). If you want to view the entire array, you can simply use array,.

If your array is on the heap, you can expand it in the watch window, but to see a specific range of values, the usage is slightly different: ((T*) array +), (note that this usage also works for multidimensional arrays on the heap). But in this case, T is the type of exponential group element.

If you are using MFC, use the 'array' container, such as CArray, CDWordArray,CStringArray, etc. Of course you can use the same filtering method. In addition, you must look at the m_pData member of array, which is the real cache that holds the data.

Tip 5: avoid entering unnecessary functions

In many cases, when debugging code, you may enter functions you want to skip, such as constructors, assignments, or other things. What bothers me most is the CString constructor. Here is an example. When you are ready to step into the take_a_string () function, first go to the constructor of CString.

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 entire namespaces to skip. The method of implementing it has also changed, going back to the days when you used VS6, usually specified through the autoexp.dat file. Vistual Studio 2002 changed to use registry settings. To skip some functions, you need to add some values to the registry (details are as follows):

The actual location depends on your Vistual Studio version and operating system platform (x86 or x64, because the registry can only be browsed under 64-bit Windows). The name of the value is a number, which represents the priority of the rule; the higher the number, the higher the priority. The value data is the REG_ SZ value of a regular expression that specifies how to filter and execute.

To avoid entering any CString methods, I added the following rule:

With this, even if you force into take_a_string () in the example above, the debugger skips the constructor of CString.

Read more:

How to avoid entering a function by using the Visual C++ debugger

Use AutoExp.dat to adjust the debugger

Tip 6: start the debugger Launch the debugger from code from the code

You may rarely need to attach a debugger to a program, but you can't do this in the Attach window (perhaps because the interrupt occurs too quickly to catch it), nor can you start the program in the debugger in the first place. You can generate interrupts in the program to give the debugger a chance to attach by calling the internal _ degbugbreak ().

The copy code is as follows:

Void break_for_debugging () {

_ _ debugbreak ()

}

In fact, there are other ways to do this, such as triggering interrupt 3, but this only applies to x86 platforms (ASM is no longer supported by the clocked 64-bit). There is also the DebugBreak () function, but it is not easy to use, so internal methods are recommended here.

The copy code is as follows:

_ _ asm int 3

The program stops running when it runs the internal method, and you have the opportunity to attach the debugger to the process.

Read more:

Internal method _ debugbreak

Setting breakpoints and assertions is indispensable at any time.

Debugging of Visual Studio 20005Universe 2008, part IV: setting the code for the debugger

Tip 7: print in the output window

You can display a specific piece of text in the debugger's output window by calling DebugOutputString. Without an attached debugger, the function does nothing.

Read more:

Function OutputDebugString

The calling mechanism of function OutputDebugString

Tip 8: isolate memory leaks

Memory leaks are an important issue in native development, and detecting memory leaks is a serious challenge, especially in large projects. Vistual Studio can provide reports to detect memory leaks, and other applications (free or commercial) can also help you detect memory leaks. In some cases, you can use a debugger to interrupt when some memory allocation eventually leads to a leak. But you have to find a reproducible allocation number (though not that easy). If this can be done, the debugger will not break until the program is executed.

Let's take a look at the following code, which allocates 8 bytes, but never releases the allocated memory. Visual Studio provides a report on the object that caused the memory leak. Run it several times and you will find that it is always the same allocation number (341).

The copy code is as follows:

Void leak_some_memory ()

{

Char* buffer = new char [8]

}

Dumping objects->

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

Data:

CD CD CD CD CD CD CD CD

The steps to break at a specific (repeatable) location are as follows:

Make sure you have enough reporting modes for memory leaks (refer to using the CRT library to detect memory leaks)

Run the program several times until you can find a reproducible allocation number in the memory leak report after the program runs, such as (341) in the previous example.

Set a breakpoint at the beginning of the program so that you can interrupt as soon as possible.

When the initial interrupt occurs, the Name bar of the watch window will display: {, msvcr90d.dll} _ crtBreakAlloc, and write the location number you are looking for in the Value column

Continue debugging (F5)

The execution of the program stops at the specified location, and you can use the call stack to be directed to the piece of code triggered by that location.

Following these steps, in the previous example, the cause of the memory leak can be identified using the assigned number (341).

Tip 9: debug the release

Debugging and publishing are two different purposes. The debug configuration is for development, while the release configuration, as the name implies, is used as the final version of the program, because it must strictly comply with the quality requirements of the release, and the configuration contains settings for interrupting debugging of the optimization section and the debug version. And, sometimes, debug the release just like you debug the release. To do this, you need to make some changes in the configuration. But in this case, you are no longer debugging the release, but a hybrid version of debugging and release.

There are some other things you should do. Here are some things you must do:

The configuration of C _ Debug Information Format + > General > should be "Program Database (/ Zi)"

The configuration of C _ Optimization + > Optimization > should be "Disabld (/ Od)"

Configuring Linker > Debugging > Generate Debug Info should be "Yes/ (DEBUG)"

As shown in the figure:

Read more: how to debug a release

Tip 10: remote debugging

Another important debugging is remote debugging, which is a bigger topic and has been mentioned many times. Here I will just make a brief summary:

You need to install remote debugging monitoring on the remote machine.

Remote debugging monitoring must be run as an administrator, and the user must belong to the administrators group

When you run the monitor, a new service will be opened, and the name of the service must be the value of the Qualifier combo box in Visual Studio's Attach to Progress window.

Firewalls on remote and local machines must allow communication between Visual Studio and remote debug monitoring

PDB files are the key to debugging; in order for VisualStudio to load them automatically, the following conditions must be met:

1) the local PDB file must be available (place a corresponding module in the same path on the remote machine).

2) the managed PDB culture on the remote machine must be available.

Remote debugging monitoring download:

Visual Studio 2008 Service Pack 1 Remote Debugger

Microsoft Visual Studio 2010 Remote Debugger

This is the end of the content of "what are the debugging skills of Visual Studio native development". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.