20 debugging tips for native development with Visual Studio

川长思鸟来 2022-04-10 07:21 145阅读 0赞

真心感觉不错，特赶紧拿来分享～

转自 CodeProject：[http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De][http_www.codeproject.com_Articles_469416_10-More-Visual-Studio-Debugging-Tips-for-Native-De]

转自 CodeProject：[http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati][http_www.codeproject.com_Articles_518159_10-Even-More-Visual-Studio-Debugging-Tips-for-Nati]

# 10 More Visual Studio Debugging Tips for Native Development #

By [Marius Bancila][], 30 Dec 2012

<table> 
 <tbody> 
  <tr> 
   <td> 
    <div style=""> 
     <table> 
      <tbody> 
       <tr> 
        <td><span></span> 
         <div style="width:139px; height:19px; position:relative"> 
          <div style="width:138px; height:19px"> 
           <img src="http://s.codeproject.com/script/Ratings/Images/stars-fill-lg.png" alt="" style="border-width:0px"> 
          </div> 
          <div style="width:1px; height:19px; position:relative"> 
           <img src="http://s.codeproject.com/script/Ratings/Images/stars-empty-lg.png" alt="" style="border-width:0px; top:0px; right:0px; position:absolute"> 
          </div> 
         </div> </td> 
        <td><span><span>4.98</span> (<span>65 votes</span>)</span></td> 
       </tr> 
      </tbody> 
     </table> 
     <div> 
      <div style="width:150px!important"> 
       <div> 
        <table title="Voting Distribution. Recent data only"> 
         <tbody> 
          <tr> 
           <td><img title="" alt="" src="http://s.codeproject.com/Images/t.gif" width="20" height="1"><br> <span title="0 votes">1</span></td> 
           <td><img title="" alt="" src="http://s.codeproject.com/Images/t.gif" width="20" height="1"><br> <span title="0 votes">2</span></td> 
           <td><img title="" alt="" src="http://s.codeproject.com/Images/t.gif" width="20" height="1"><br> <span title="0 votes">3</span></td> 
           <td><img title="2 votes, 3.1%" alt="2 votes, 3.1%" src="http://www.codeproject.com/script/Ratings/Images/pollcol.gif" width="20" height="1"><br> <span title="2 votes">4</span></td> 
           <td><img title="63 votes, 96.9%" alt="63 votes, 96.9%" src="http://www.codeproject.com/script/Ratings/Images/pollcol.gif" width="20" height="50"><br> <span title="63 votes">5</span></td> 
          </tr> 
         </tbody> 
        </table> 
        <div>
          4.98/5 - 65 votes 
        </div> 
        <div>
          μ 4.98, σ 
         <sub><span style="font-size:12px">a</span></sub> 1.08 [ 
         <a href="http://www.codeproject.com/KB/FAQs/RatingReputationFAQ.aspx#noisefilter" rel="nofollow">?</a>] 
        </div> 
       </div> 
      </div> 
      <div> 
       <div></div> 
      </div> 
     </div> 
    </div> </td> 
   <td>&nbsp;</td> 
  </tr> 
 </tbody> 
</table>

![award24.gif][] Prize winner in Competition  "Best C++ article of October 2012"

I have recently run onto this article by Ivan Shcherbakov called [ 10+ powerful debugging tricks with Visual Studio][10_ powerful debugging tricks with Visual Studio]. Though the article presents some rather basic tips of debugging with Visual Studio, there are others at least as helpful as those. Therefore I put together a list of ten more debugging tips for native development that work with at least Visual Studio 2008. (If you work with managed code, the debugger has even more features and there are several articles on CodeProject that present them.) Here is my list of additional tips:

*  [1. Break on Exception][]
 *  [2. Pseudo-variables in Watch Windows][]
 *  [3. Watch Heap Objects After Symbol Goes out of Scope][]
 *  [4. Watch a Range of Values Inside an Array][]
 *  [5. Avoid Stepping into Unwanted Functions][]
 *  [6. Launch the debugger from code][]
 *  [7. Print to Output Window][]
 *  [8. Memory Leaks Isolation][]
 *  [9. Debug the Release Build][]
 *  [10. Remote Debugging][]

For more debugging tips check the second article in the series, [ 10 Even More Visual Studio Debugging Tips for Native Development][http_www.codeproject.com_Articles_518159_10-Even-More-Visual-Studio-Debugging-Tips-for-Nati].

## Tip 1: Break on Exception ##

It is possible to instruct the debugger to break when an exception occurs, before a handler is invoked. That allows you to debug your application immediately after the exception occurs. Navigating the Call Stack should allow you to figure the root cause of the exception.

Visual Studio allows you to specify what category or particular exception you want to break on. A dialog is available from Debug > Exceptions menu. You can specify native (or managed) exceptions and aside from the default exceptions known to the debugger, you can add your custom exceptions.

![vsdbg_01_breakex1.png][]

Here is an example with the debugger breaking when a std::exception is thrown.

![vsdbg_01_breakex2.png][]

Additional readings:

*  [How to: Break When an Exception is Thrown][How to_ Break When an Exception is Thrown]
 *  [How to: Add New Exceptions][How to_ Add New Exceptions]

## Tip 2: Pseudo-variables in Watch Windows ##

The Watch windows or the QuickWatch dialog support some special (debugger-recognized) variables called pseudovariables. The documented one include:

*  **$tid** – the thread ID of the current thread
 *  **$pid** – the process ID
 *  **$cmdline** – the command line string that launched the program
 *  **$user** – information for the account running the program
 *  **$*registername*** – displays the content of the register *registername*

However, one that is quite useful is a pseudo-variable for the last error:

*  **$err** – displays the numeric code of the last error
 *  **$err, hr** – displays the message of the last error

![vsdbg_02_err.png][]

Additional readings:

*  [Pseudovariables][]

## Tip 3: Watch Heap Objects After Symbol Goes out of Scope ##

Sometimes you'd like to watch the value of an object (on the heap) even after the symbol goes of scope. When that happens, the variable in the Watch window is disabled and cannot be inspected any more (nor updated) even if the object is still alive and well.  It is possible to continue to watch it in full capability if you know the address of the object. You can then cast the address to a pointer of the object type and put that in the Watch window.

In the example bellow, \_foo is no longer accessible in the Watch window after stepping out of do\_foo(). However, taking its address and casting it to foo\* we can still watch the object.

![vsdbg_03_symout.png][]

## Tip 4: Watch a Range of Values Inside an Array ##

If you work with large arrays (let say at least some hundred elements, but maybe even less) expanding the array in the Watch window and looking for some particular range of elements is cumbersome, because you have to scroll a lot.  And if the array is allocated on the heap you can't even expand its elements in the Watch window.  There is a solution for that. You can use the syntax **(array + <offset>), <count>** to watch a particular range of <count> elements starting at the <offset> position (of course, array here is your actual object).  If you want to watch the entire array, you can simply say **array, <count>**.

![vsdbg_04_arraysheap.png][]

If your array is on the heap, then you can expand it in the Watch window, but to watch a particular range you'd have to use a slightly different the syntax: **((T\*)array + <offset>), <count>** (notice this syntax also works with arrays on the heap). In this case T is the type of the array's elements.

![vsdbg_04_arraysheap.png][]

If you work with MFC and use the "array" containers from it, like CArray, CDWordArray, CStringArray, etc., you can of course apply the same filtering, except that you must watch the m\_pData member of the array, which is the actual buffer holding the data.

![vsdbg_04_arraysmfc.png][]

## Tip 5: Avoid Stepping into Unwanted Functions ##

Many times when you debug the code you probably step into functions you would like to step over, whether it's constructors, assignment operators or others. One of those that used to bother me the most was the `CString` constructor.  Here is an example when stepping into `take_a_string()` function first steps into `CString`'s constructor.

![minus.gif][]  Collapse | [Copy Code][]

void take_a_string(CString const &text)
    {
    }
    
    void test_string()
    {
       take_a_string(_T("sample"));
    }

![vsdbg_05_cstring.png][]

Luckily it is possible to tell the debugger to step over some methods, classes or entire namespaces.  The way this was implemented has changed. Back in the days of VS 6 this used to be specified through the autoexp.dat file.  Since Visual Studio 2002 this was changed to Registry settings. To enable stepping over functions you need to add some values in Registry (you can find all the details [here][]):

*  The actual location depends on the version of Visual Studio you have and the platform of the OS (x86 or x64, because the Registry has to views for 64-bit Windows)
 *  The value name is a number and represents the priority of the rule; the higher the number the more precedence the rules has over others.
 *  The value data is a REG\_SZ value representing a regular expression that specifies what to filter and what action to perform.

To skip stepping into any `CString` method I have added the following rule:

![vsdbg_05_regedit.png][]

Having this enabled, even when you press to step into `take_a_string()` in the above example the debugger skips the CString's constructor.

Additional readings:

*  [How to Not Step Into Functions using the Visual C++ Debugger][here]
 *  [Tune the debugger using AutoExp.dat][]

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

Seldom you might need to attach with the debugger to a program, but you cannot do it with the Attach window (maybe because the break would occur too fast to catch by attaching), nor you can start the program in debugger in the first place. You can cause a break of the program and give the debugger a chance to attach by calling the `__debugbreak()` intrinsic.

![minus.gif][]  Collapse | [Copy Code][]

void break_for_debugging()
    {
       __debugbreak();
    }

There are actually other ways to do this, such as triggering interruption 3, but this only works with x86 platforms (ASM is no longer supported for x64 in C++).  There is also a [DebugBreak()][DebugBreak] function, but this is not portable, so the intrinsic is the recommended method.

![minus.gif][]  Collapse | [Copy Code][]

__asm int 3;

When your program executes the intrinsic it stops, and you get a chance to attach a debugger to the process.

![vsdbg_06_debugbreak1.png][]

![vsdbg_06_debugbreak2.png][]

![vsdbg_06_debugbreak3.png][]

Additional readings:

*  [\_\_debugbreak intrinsic][debugbreak intrinsic]
 *  [DebugBreak and ASSERTs that work always anywhere][]
 *  [Debugging with Visual Studio 2005/2008, Part 4: Setting up Code for the Debugger][Debugging with Visual Studio 2005_2008_ Part 4_ Setting up Code for the Debugger]

## Tip 7: Print to Output Window ##

It is possible to show a particular text in the debugger's output window by calling `DebugOutputString`. If there is no debugger attached, the function does nothing.

![vsdbg_07_outputwnd.png][]

*  [OutputDebugString function][]
 *  [Mechanism of OutputDebugString][]

## Tip 8: Memory Leaks Isolation ##

Memory leaks are an important problem in native development and finding them could be a serious challenging especially in large projects. Visual Studio provides reports about detected memory leaks and there are other applications (free or commercial) to help you with that. In some situations though, it is possible to use the debugger to break when an allocation that eventually leaks is done. To do this however, you must find a reproducible allocation number (which might not be that easy though). If you are able to do that, then the debugger can break the moment that is performed.

Let's consider this code that allocates 8 bytes, but never releases the allocated memory. Visual Studio displays a report of the leaked objects, and running this several times I could see it's always the same allocation number (341).

![minus.gif][]  Collapse | [Copy Code][]

void leak_some_memory()
    {
       char* buffer = new char[8];
    }
    
    Dumping objects ->
    d:\marius\vc++\debuggingdemos\debuggingdemos.cpp(103) : {
        341} normal block at 0x00F71F38, 8 bytes long.
     Data: <        > CD CD CD CD CD CD CD CD 
    Object dump complete.

The steps for breaking on a particular (reproducible) allocation are:

*  Make sure you have the adequate reporting mode for memory leaks (see [ Finding Memory Leaks Using the CRT Library][Finding Memory Leaks Using the CRT Library]).  
 *  Run the program several times until you find reproducible allocation numbers (\{341\} in my example above) in the memory leaks report at the end of running the program.  
 *  Put a breakpoint somewhere at the start of the program so you can break as early as possible. 
 *  Start the application with the debugger.  
 *  When the initial breakpoint is hit, in the watch window write in the Name column: **\{,,msvcr90d.dll\}\_crtBreakAlloc**, and in Value column put the allocation number that you want to investigate.  
 *  Continue debugging (F5).  
 *  The execution stops at the specified allocation. You can use the Call Stack to navigate back to your code where the allocation was triggered.

Following these steps for my example with allocation number 341 I was able to identify the source of the leak:

![vsdbg_08_leakmem.png][]

## Tip 9: Debug the Release Build ##

Debug and Release builds are meant for different purposes. While a Debug configuration is used for development, a Release configuration, as the name implies should be used for the final version of a program. Since it's supposed that the application meets the required quality to be published, such a configuration contains optimizations and settings that break the debugging experience of a Debug build. Still, sometimes you'd like to be able to debug the Release build the same way you debug the Debug build. To do that, you need to perform some changes in the configuration.  However, in this case one could argue you no longer debug the Release build, but rather a mixture of the Debug and the Release builds.

![vsdbg_09_release1.png][]

There are several things you should do; the mandatory ones are:

*  C/C++ > General > Debug Information Format should be "Program Database (/Zi)"
 *  C/C++ > Optimization > Optimization should be "Disabled (/Od)"
 *  Linker > Debugging > Generate Debug Info should be "Yes (/DEBUG)"

![vsdbg_09_release2.png][]

Additional readings:

*  [How to: Debug a Release Build][How to_ Debug a Release Build]

## Tip 10: Remote Debugging ##

Another important debugging experience is remote debugging. This is a larger topic, covered many times, so I just want to summarize a bit.

*  You need Remote Debugging Monitor installed on the remote machine
 *  The Remote Debugging Monitor must run "As Administrator" and the user must be a member of the Administrators group
 *  When you run the monitor it starts a new server whose name you must use in the Visual Studio's Attach to Progress window in the Qualifier combo.   
    
    ![vsdbg_10_remote1.png][]
    
    ![vsdbg_10_remote2.png][]
 *  The firewalls on the remote and local machine must allow communication between Visual Studio and the Remote Debugging Monitor
 *  To be able to debug, the PDB files are key; in order for the Visual Studio debugger to be able to load them automatically   
    
     *  the native PDBs must be available on the local machine (on the same path where the corresponding module is located on the remote machine),
     *  the managed PDBs must be available on the remote machine.

Remote Debugging Monitor downloads:

*  [Visual Studio 2008 Service Pack 1 Remote Debugger][]
 *  [Microsoft Visual Studio 2010 Remote Debugger][]

Additional readings:

*  [Setting Up Remote Debugging][]
 *  [How to: Run the Remote Debugging Monitor][How to_ Run the Remote Debugging Monitor]
 *  [Loading debug symbols when remote debugging: native vs managed][Loading debug symbols when remote debugging_ native vs managed]
 *  [PDB Files: What Every Developer Must Know][PDB Files_ What Every Developer Must Know]
 *  [Visual Studio Remote Debugging and PDB Files][]
 *  [How to: Specify Symbol Locations and Loading Behavior][How to_ Specify Symbol Locations and Loading Behavior]

# 10 Even More Visual Studio Debugging Tips for Native Development #

By [Marius Bancila][], 30 Dec 2012

<table> 
 <tbody> 
  <tr> 
   <td> 
    <div style=""> 
     <table> 
      <tbody> 
       <tr> 
        <td><span></span> 
         <div style="width:139px; height:19px; position:relative"> 
          <div style="width:137px; height:19px"> 
           <img src="http://s.codeproject.com/script/Ratings/Images/stars-fill-lg.png" alt="" style="border-width:0px"> 
          </div> 
          <div style="width:2px; height:19px; position:relative"> 
           <img src="http://s.codeproject.com/script/Ratings/Images/stars-empty-lg.png" alt="" style="border-width:0px; top:0px; right:0px; position:absolute"> 
          </div> 
         </div> </td> 
        <td><span><span>4.94</span> (<span>19 votes</span>)</span></td> 
       </tr> 
      </tbody> 
     </table> 
     <div> 
      <div style="width:150px!important"> 
       <div> 
        <table title="Voting Distribution. Recent data only"> 
         <tbody> 
          <tr> 
           <td><img title="" alt="" src="http://s.codeproject.com/Images/t.gif" width="20" height="1"><br> <span title="0 votes">1</span></td> 
           <td><img title="" alt="" src="http://s.codeproject.com/Images/t.gif" width="20" height="1"><br> <span title="0 votes">2</span></td> 
           <td><img title="" alt="" src="http://s.codeproject.com/Images/t.gif" width="20" height="1"><br> <span title="0 votes">3</span></td> 
           <td><img title="1 vote, 5.3%" alt="1 vote, 5.3%" src="http://www.codeproject.com/script/Ratings/Images/pollcol.gif" width="20" height="2"><br> <span title="1 vote">4</span></td> 
           <td><img title="18 votes, 94.7%" alt="18 votes, 94.7%" src="http://www.codeproject.com/script/Ratings/Images/pollcol.gif" width="20" height="50"><br> <span title="18 votes">5</span></td> 
          </tr> 
         </tbody> 
        </table> 
        <div>
          4.94/5 - 19 votes 
        </div> 
        <div>
          μ 4.95, σ 
         <sub><span style="font-size:12px">a</span></sub> 1.05 [ 
         <a href="http://www.codeproject.com/KB/FAQs/RatingReputationFAQ.aspx#noisefilter" rel="nofollow">?</a>] 
        </div> 
       </div> 
      </div> 
      <div> 
       <div></div> 
      </div> 
     </div> 
    </div> </td> 
   <td>&nbsp;</td> 
  </tr> 
 </tbody> 
</table>

My [ previous article][http_www.codeproject.com_Articles_469416_10-More-Visual-Studio-Debugging-Tips-for-Native-De] on debugging tips for Visual Studio was met with so much interest that determined me to share even more debugging techniques. Therefore you can find below a list of other helpful tips for debugging native applications (continuing the numbering from the previous article). These tips work with Visual Studio 2005 or newer (and at least some of them with older versions too). You can get additional information about each technique if you follow the recommended readings.

1.  [Data breakpoints][]
2.  [Renaming threads][]
3.  [Breaking on particular threads][]
4.  [(Roughly) Timing Execution][Roughly_ Timing Execution]
5.  [Formatting numbers][]
6.  [Formatting (memory) data][Formatting _memory_ data]
7.  [Breaking on system DLLs][]
8.  [Loading symbols][]
9.  [Memory leak reports in MFC][]
10. [Debugging ATL][]

## Tip 11: Data breakpoints ##

It is possible to instruct the debugger to break when data at a certain memory location changes. It is however only possible to create 4 such hardware data breakpoints at a time. Data breakpoints can be added only during debugging, either from the menu (Debug > New Breakpoint > New Data Breakpoint) or from the Breakpoints window.

![vsdbg2_1_1.png][]

You can use either a memory address or an expression that evaluates to an address. Even though you can watch both values on the stack and on the heap, I'd say this feature is mostly helpful to find when values on the heap are changed. This can be a great help in identifying memory corruption.

In the example below, the value of a pointer is changed, instead of the value of the object it points to. To figure out where that happens I set a breakpoint on the memory where the value of the pointer is stored, i.e. &ptr (notice this must happen after the pointer is initialized). When the data changes, which means someone alters the value of the pointer, the debugger breaks and I can figure which piece of code is responsible for that.

[![vsdbg2_1_2.png][]][vsdbg2_1_2.png]

Additional readings:

*  [How Can I Find Out If My Pointers Corrupt a Memory Address?][How Can I Find Out If My Pointers Corrupt a Memory Address]
 *  [How Can I Find Out Where My Pointer Is Getting Changed?][How Can I Find Out Where My Pointer Is Getting Changed]

## Tip 12: Renaming threads ##

When you debug multi-threaded applications the Threads window shows you what threads are created and which one is currently running. The more threads you have the harder could be to figure out what thread exactly you are looking at (especially when the same thread procedure is run by several threads, and you don't know exactly which thread instance is currently executing).

[![vsdbg2_2_1.png][]][vsdbg2_2_1.png]

The debugger allows you change the names of the threads. Use the context menu on a thread and rename it.

![vsdbg2_2_2.png][]

It is also possible to programmatically name a thread, though this is a little bit trickier and must be done after the thread has started, otherwise the debugger will re-initialize it with its default naming convention. Define and use the following function for renaming a thread.

![minus.gif][]  Collapse | [Copy Code][Copy Code 1]

typedef struct tagTHREADNAME_INFO
    {
    	DWORD dwType;        // must be 0x1000
    	LPCSTR szName;       // pointer to name (in same addr space)
    	DWORD dwThreadID;    // thread ID (-1 caller thread)
    	DWORD dwFlags;       // reserved for future use, most be zero
    } 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)
    	{
    	}
    }

Additional readings

*  [Setting a Thread Name (Unmanaged)][Setting a Thread Name _Unmanaged]

## Tip 13: Breaking on particular threads ##

Another helpful technique for multi-threading applications is to filter the breakpoints to certain threads, processes or even computers. This is possible by using the Filter command on a breakpoint.

![vsdbg2_3_1.png][]

The debugger allows you to specify any combination (AND, OR, NOT) of ThreadName, ThreadId, ProcessName, ProcessId and MachineName. Knowing how to set a thread name already can make this filtering even simpler.

Additional readings:

*  [How to: Specify a Breakpoint Filter][How to_ Specify a Breakpoint Filter]
 *  [Setting a Breakpoint Filter][]

## Tip 14: (Roughly) Timing Execution ##

In my previous article I wrote about pseudo-variables in the Watch window. One not mentioned then is **@clk**, which shows the value of a counter and can help getting a rough idea of how much time the code between two breakpoints took to execute. The value is expressed in microseconds. However, this is by no means a method to profile execution. You should use the Visual Studio profiler and/or performance timers for that.

It is possible to reset the clock by adding **@clk=0** in the Watch window or executing that in the Immediate window. Therefore to figure how much time some piece of code took to execute do the following:

*  Set a breakpoint at the beginning of the block
 *  Set a breakpoint at the end of the block
 *  Add @clk in the Watch window
 *  When the first breakpoint is hit type @clk=0 in the Intermediate window.
 *  Run the program until the breakpoint at the end of the block is hit and check the value of @clk in the Watch window.

Notice there are tips on the web that instruct you to add two expressions in the Watch window: @clk followed by a @clk=0, which would allegedly reset the clock each time a breakpoint is hit. This used to worked in older versions of Visual Studio, but no longer works (for sure in VS2005 and newer).

Additional readings:

*  [Debugging Tips - @CLK][Debugging Tips - _CLK]

## Tip 15: Formatting numbers ##

When you watch variables in the Watch or Quick Watch window, the values are displayed using the default pre-defined visualizers. When it comes to numbers, these are displayed according to their types (integer, float, double) and using the decimal base. But you can force the debugger to show the numbers as a different type, or with a different numeric base, or both.

To change the displayed type prefix the variable with:

*  **by** for unsigned char (aka unsigned byte)
 *  **wo** for unsigned short (aka unsigned word)
 *  **dw** for unsigned long (aka unsigned double word)

To change the displayed base suffix the variable name with:

*  **, d** or **, i** for signed decimal
 *  **, u** for unsigned decimal
 *  **, o** for unsigned octal
 *  **, x** for lowercase hex or **, X** for uppercase hex

![vsdbg2_5_1.png][] ![vsdbg2_5_2.png][]

Additional readings:

*  [C++ Debugger Tips][C_ Debugger Tips]

## Tip 16: Formatting (memory) data ##

Apart from numbers, the debugger can also show formatted memory values, up to 64 bytes, in the Watch window. You can use one of the following specifiers after an expression (variable or memory address) to format the data:

*  **mb** or **m** \- 16 bytes in hex followed by 16 ASCII characters
 *  **mw** \- 8 words
 *  **md** \- 4 double words
 *  **mq** \- 2 quad-words
 *  **ma** \- 64 ASCII characters
 *  **mu** \- 2-byte UNICODE characters

[![vsdbg2_6_1.png][]][vsdbg2_6_1.png]

Additional readings:

*  [Format Specifiers in C++][Format Specifiers in C]
 *  [Debugging Tips in Developer Studio][]

## Tip 17: Breaking on system DLLs ##

Sometimes it's useful to break when some function in a DLL, like a system DLL (think kernel32.dll or user32.dll) is called. To do this one must use the context operator provided by the native debugger. You can qualify a breakpoint location, variable name or expression:

*  \{\[function\],\[source\],\[module\] \} location
 *  \{\[function\],\[source\],\[module\] \} variable\_name
 *  \{\[function\],\[source\],\[module\] \} expression

The braces can contain any combination of function name, source and module, but the commas must not be omitted.

Let's say we want to break when CreateThread is called. This function is exported from kernel32.dll, and therefore the context operator should look like this: **\{,,kernel32.dll\}CreateThread**. However, this does not work as the operator requires the decorated name of CreateThread. One could use [ DBH.exe][DBH.exe] to figure out what the decorated name for a specific function is.

Here is how you can figure the decorated name for CreateThread:

![minus.gif][]  Collapse | [Copy Code][Copy Code 1]

C:\Program Files (x86)\Debugging Tools for Windows (x86)>dbh.exe -s:srv*C:\Symbo
    ls*http://msdl.microsoft.com/Download/Symbols -d C:\Windows\SysWOW64\kernel32.dl
    l 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 :   ??_C@_0BC@PKLIFPAJ@SHCreateThreadRef?$AA@
         7            107309c :   ??_C@_0BD@CIEDBPNA@TF_CreateThreadMgr?$AA@
         8            102ce87 :   _CreateThreadpoolCleanupGroupStub@0
         9            1038fe3 :   _CreateThreadpoolIoStub@16
         a            102e6f0 :   _CreateThreadpoolTimer@12
         b            102e759 :   _CreateThreadpoolWaitStub@12
         c            102ce8e :   _CreateThreadpoolCleanupGroup@0
         d            102e6e3 :   _CreateThreadpoolTimerStub@12
         e            1038ff0 :   _CreateThreadpoolIo@16
         f            102e766 :   _CreateThreadpoolWait@12
        10            102e6aa :   _CreateThreadpoolWorkStub@12
        11            1032359 :   _CreateThreadpool@4

Looks like the actual name is \_CreateThreadStub@24. So we should create a breakpoint at **\{,,kernel32.dll\}\_CreateThreadStub@24**.

![vsdbg2_7_1.png][]

Run the program and when it breaks, ignore the message that there is no source code associated with the breakpoint.

![vsdbg2_7_2.png][]

Use the Call Stack window to navigate to your code that made the call to the function.

[![vsdbg2_7_3.png][]][vsdbg2_7_3.png]

Additional readings:

*  [How to set breakpoints without source code in Visual Studio 2010][]
 *  [Context Operator (C/C++ Language Expressions)][Context Operator _C_C_ Language Expressions]
 *  [How to: Set a Function Breakpoint][How to_ Set a Function Breakpoint]

## Tip 18: Loading symbols ##

When you debug your application the Call Stack window might not display a full call stack, but skip information about system DLLs (such as kernel32.dll and user32.dll).

![vsdbg2_8_1.png][]

It is possible to get the full stack by loading the symbols for these DLLs. This can be done directly from the Call Stack window, using the context menu. You can either download from the pre-specified symbol path, or from Microsoft's symbols server (if it's a system DLL). After the symbols are downloaded and loaded into the debugger, the Call Stack updates.

[![vsdbg2_8_2.png][]][vsdbg2_8_2.png]

The symbols can also be loaded from the Modules window.

[![vsdbg2_8_3.png][]][vsdbg2_8_3.png]

Once downloaded, the symbols are stored in a cache that can be configured from Tools > Options > Debugging > Symbols.

[![vsdbg2_8_4.png][]][vsdbg2_8_4.png]

## Tip 19: Memory leak reports in MFC ##

If you want to get memory leak reports in MFC application you can re-defined the new operator with a DEBUG\_NEW macro, which is a modified version of the new operator that keeps track of the filename and line number for each object that it allocates. In a release build DEBUG\_NEW resolves to operator new.

The wizard generated MFC source files contain the following pre-processor directives after the \#includes:

![minus.gif][]  Collapse | [Copy Code][Copy Code 1]

#ifdef _DEBUG
    #define new DEBUG_NEW
    #endif

This is how you can re-define the new operator.

However, many STL headers are incompatible with this version of operator new. If you include <map>, <vector>, <list>, <string> and others after you re-define operator new you get errors like this (shown for <vector>):

![minus.gif][]  Collapse | [Copy Code][Copy Code 1]

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 types
    1>        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<char>(size_t,_Ty *)' being compiled
    1>        with
    1>        [
    1>            _Ty=char
    1>        ]
    1>        c:\program files (x86)\microsoft visual studio 9.0\vc\include\xmemory(144) : while compiling class template member function 'char *std::allocator<_Ty>::allocate(std::allocator<_Ty>::size_type)'
    1>        with
    1>        [
    1>            _Ty=char
    1>        ]
    1>        c:\program files (x86)\microsoft visual studio 9.0\vc\include\xstring(2216) : see reference to class template instantiation 'std::allocator<_Ty>' being compiled
    1>        with
    1>        [
    1>            _Ty=char
    1>        ]

The solution is to always include these STL headers before redefining new with DEBUG\_NEW.

Additional readings:

*  [DEBUG\_NEW][DEBUG_NEW]

## Tip 20: Debugging ATL ##

When you develop ATL COM components you can get some help from the debugger to watch calls for QueryInterface, AddRef and Release on your COM objects. This support is not enabled by default, but you can specify two macros to the preprocessor definitions or the pre-compiled header file. When those macros are defined information about these calls is displayed in the Output window.

These two macros are:

*  **\_ATL\_DEBUG\_QI** displays the name of each interfaces that is queried for on your objects. It must be defined before atlcom.h is included.
 *  **\_ATL\_DEBUG\_INTERFACES** displays current reference count for the interface together with the class name and interface name, every time AddRef or Release is called. It must be defined before atlbase.h is included.

Additional readings:

*  [Debugging Tips][]
 *  [ATL Debugging Techniques][]
 *  [How does \_ATL\_DEBUG\_INTERFACES work?][How does _ATL_DEBUG_INTERFACES work]

[http_www.codeproject.com_Articles_469416_10-More-Visual-Studio-Debugging-Tips-for-Native-De]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De
[http_www.codeproject.com_Articles_518159_10-Even-More-Visual-Studio-Debugging-Tips-for-Nati]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati
[Marius Bancila]: http://www.codeproject.com/script/Membership/View.aspx?mid=562357
[award24.gif]: http://s.codeproject.com/images/award24.gif
[10_ powerful debugging tricks with Visual Studio]: http://www.codeproject.com/Articles/359801/10plus-powerful-debugging-tricks-with-Visual-Studi
[1. Break on Exception]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip1
[2. Pseudo-variables in Watch Windows]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip2
[3. Watch Heap Objects After Symbol Goes out of Scope]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip3
[4. Watch a Range of Values Inside an Array]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip4
[5. Avoid Stepping into Unwanted Functions]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip5
[6. Launch the debugger from code]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip6
[7. Print to Output Window]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip7
[8. Memory Leaks Isolation]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip8
[9. Debug the Release Build]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip9
[10. Remote Debugging]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#tip10
[vsdbg_01_breakex1.png]: /images/20220402/f866bd866992490387fa625eb4996bc6.png
[vsdbg_01_breakex2.png]: /images/20220402/09c55fd99fef4b5ba7a2639bc8b3e571.png
[How to_ Break When an Exception is Thrown]: http://msdn.microsoft.com/en-us/library/d14azbfh.aspx
[How to_ Add New Exceptions]: http://msdn.microsoft.com/en-us/library/tw4t258c.aspx
[vsdbg_02_err.png]: /images/20220402/a3f05edf78274a56abd0c0411e739774.png
[Pseudovariables]: http://msdn.microsoft.com/en-us/library/ms164891.aspx
[vsdbg_03_symout.png]: /images/20220402/84275d67e49e4ec5b3d412615ec24ec8.png
[vsdbg_04_arraysheap.png]: /images/20220402/8ce8ebeddf084b6bba7a1da706a24b6c.png
[vsdbg_04_arraysmfc.png]: /images/20220402/29e3a091e8364016866d1b3a16192cd1.png
[minus.gif]: /images/20220402/484224fa96e847bca800ac9d8ee67db6.png
[Copy Code]: http://www.codeproject.com/Articles/469416/10-More-Visual-Studio-Debugging-Tips-for-Native-De#
[vsdbg_05_cstring.png]: /images/20220402/f4a98c77fcf84f21be1b5b26137f161a.png
[here]: http://blogs.msdn.com/b/andypennell/archive/2004/02/06/69004.aspx
[vsdbg_05_regedit.png]: /images/20220402/f0706a2bca2344cebe1e4d8dde75320f.png
[Tune the debugger using AutoExp.dat]: http://www.codeguru.com/cpp/v-s/debug/article.php/c1281/Tune-the-debugger-using-AutoExpdat.htm
[DebugBreak]: http://msdn.microsoft.com/en-us/library/windows/desktop/ms679297.aspx
[vsdbg_06_debugbreak1.png]: /images/20220402/ce7921f32f1b4a9e9cfa11bb1413c939.png
[vsdbg_06_debugbreak2.png]: /images/20220402/14b0254d4b464a7eba80128e731be960.png
[vsdbg_06_debugbreak3.png]: /images/20220402/c68a795e9beb4dfd9b0a443d41ae5fa3.png
[debugbreak intrinsic]: http://msdn.microsoft.com/en-us/library/f408b4et.aspx
[DebugBreak and ASSERTs that work always anywhere]: http://www.codeproject.com/Articles/10022/DebugBreak-and-ASSERTs-that-work-always-anywhere
[Debugging with Visual Studio 2005_2008_ Part 4_ Setting up Code for the Debugger]: http://www.cprogramming.com/tutorial/visual_studio_debugging_code_setup.html
[vsdbg_07_outputwnd.png]: /images/20220402/1664e98b66b24ff3a763488586f472fd.png
[OutputDebugString function]: http://msdn.microsoft.com/en-us/library/windows/desktop/aa363362.aspx
[Mechanism of OutputDebugString]: http://www.codeproject.com/Articles/23776/Mechanism-of-OutputDebugString
[Finding Memory Leaks Using the CRT Library]: http://msdn.microsoft.com/en-us/library/x98tx3cf.aspx
[vsdbg_08_leakmem.png]: /images/20220402/fd2cb5aa36e64152a56f25a933ace70d.png
[vsdbg_09_release1.png]: /images/20220402/b72ad1416bcf44c38282338cd9a4d5da.png
[vsdbg_09_release2.png]: /images/20220402/52b1639287b143f2be7d7a850b7f8ae6.png
[How to_ Debug a Release Build]: http://msdn.microsoft.com/en-us/library/fsk896zz.aspx
[vsdbg_10_remote1.png]: /images/20220402/d9fc5c99fac54c25bc8518043df3e07f.png
[vsdbg_10_remote2.png]: /images/20220402/53f10bd3afae42ae9e95724aa33d6fab.png
[Visual Studio 2008 Service Pack 1 Remote Debugger]: http://www.microsoft.com/en-us/download/details.aspx?id=10647
[Microsoft Visual Studio 2010 Remote Debugger]: http://www.microsoft.com/en-us/download/details.aspx?id=475
[Setting Up Remote Debugging]: http://msdn.microsoft.com/en-us/library/bt727f1t.aspx
[How to_ Run the Remote Debugging Monitor]: http://msdn.microsoft.com/en-us/library/xf8k2h6a.aspx
[Loading debug symbols when remote debugging_ native vs managed]: http://blogs.technet.com/b/monicaboris/archive/2004/02/16/74520.aspx
[PDB Files_ What Every Developer Must Know]: http://www.wintellect.com/CS/blogs/jrobbins/archive/2009/05/11/pdb-files-what-every-developer-must-know.aspx
[Visual Studio Remote Debugging and PDB Files]: http://www.wintellect.com/cs/blogs/jrobbins/archive/2009/05/26/visual-studio-remote-debugging-and-pdb-files.aspx
[How to_ Specify Symbol Locations and Loading Behavior]: http://msdn.microsoft.com/en-us/library/x54fht41.aspx
[Data breakpoints]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip11
[Renaming threads]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip12
[Breaking on particular threads]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip13
[Roughly_ Timing Execution]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip14
[Formatting numbers]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip15
[Formatting _memory_ data]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip16
[Breaking on system DLLs]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip17
[Loading symbols]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip18
[Memory leak reports in MFC]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip19
[Debugging ATL]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#tip20
[vsdbg2_1_1.png]: /images/20220402/d1526857f4b8438a974bafa030d634e3.png
[vsdbg2_1_2.png]: /images/20220402/046bcbeb6a1642f6afa22104cda25fe3.png
[How Can I Find Out If My Pointers Corrupt a Memory Address]: http://msdn.microsoft.com/en-us/library/w500y392.aspx
[How Can I Find Out Where My Pointer Is Getting Changed]: http://msdn.microsoft.com/en-us/library/aa292289%28v=vs.71%29.aspx
[vsdbg2_2_1.png]: /images/20220402/446359caa25544c195860676b45c69ec.png
[vsdbg2_2_2.png]: /images/20220402/ba84a8e41c9e4d4abcf50b34c6bb2da7.png
[Copy Code 1]: http://www.codeproject.com/Articles/518159/10-Even-More-Visual-Studio-Debugging-Tips-for-Nati#
[Setting a Thread Name _Unmanaged]: http://msdn.microsoft.com/en-us/library/xcb2z8hs.aspx
[vsdbg2_3_1.png]: /images/20220402/05e5bd95b8a346abab0229a7c745f0b4.png
[How to_ Specify a Breakpoint Filter]: http://msdn.microsoft.com/en-us/library/wyakk529.aspx
[Setting a Breakpoint Filter]: http://blogs.msdn.com/b/zainnab/archive/2010/05/06/setting-a-breakpoint-filter-vstipdebug0024.aspx
[Debugging Tips - _CLK]: http://nasutechtips.blogspot.ro/2011/03/debugging-tips-clk.html
[vsdbg2_5_1.png]: http://www.codeproject.com/KB/debug/518159/vsdbg2_5_1.png
[vsdbg2_5_2.png]: /images/20220402/61e2412d0bbc4dbda6fb19af8911f832.png
[C_ Debugger Tips]: http://blogs.msdn.com/b/vcblog/archive/2006/08/04/689026.aspx
[vsdbg2_6_1.png]: /images/20220402/70a0ad6aafe5495ea8ed67259c81f1c0.png
[Format Specifiers in C]: http://msdn.microsoft.com/en-us/library/75w45ekt.aspx
[Debugging Tips in Developer Studio]: http://edndoc.esri.com/arcobjects/9.1/ArcGISDevHelp/DevelopmentEnvs/COM/VCpp/Debugger.htm
[DBH.exe]: http://msdn.microsoft.com/en-us/library/windows/hardware/ff540437.aspx
[vsdbg2_7_1.png]: /images/20220402/7aeb573b0e1f417f9f7143d7d3831485.png
[vsdbg2_7_2.png]: /images/20220402/9c26e24e10dd4a9995e8686f3cf1d6e0.png
[vsdbg2_7_3.png]: /images/20220402/0e3fcd2d9c02404ca43047911ac28059.png
[How to set breakpoints without source code in Visual Studio 2010]: http://bugslasher.net/2011/03/08/how-to-set-breakpoints-without-source-code-in-visual-studio-2010/
[Context Operator _C_C_ Language Expressions]: http://msdn.microsoft.com/en-us/library/wztycb7f.aspx
[How to_ Set a Function Breakpoint]: http://msdn.microsoft.com/en-us/library/15d1wtaf.aspx
[vsdbg2_8_1.png]: /images/20220402/51c74080cb004a44a22961e564b309a3.png
[vsdbg2_8_2.png]: /images/20220402/943d3e6beebb4540a6de88aaae5cf9e6.png
[vsdbg2_8_3.png]: /images/20220402/9fbf8e3025c442d7a0984a26c0f30e58.png
[vsdbg2_8_4.png]: /images/20220402/7f52c3d0e2aa4ad39f72e20c4ad4d9fd.png
[DEBUG_NEW]: http://msdn.microsoft.com/en-us/library/tz7sxz99.aspx
[Debugging Tips]: http://www.icodeguru.com/VC%26MFC/InsideAtl/ch06h.htm
[ATL Debugging Techniques]: http://msdn.microsoft.com/en-us/library/hs48703y%28v=vs.71%29.aspx
[How does _ATL_DEBUG_INTERFACES work]: http://www.codeguru.com/cpp/com-tech/atl/atl/article.php/c87/How-does-ATLDEBUGINTERFACES-work.htm