Tag / debugging

by Ovidiu Cucu

Visual Studio 2015: How to Step into MFC Framework Code

Let’s say we have installed Visual Studio 2015 and  have started an MFC application in DEBUG mode. Now, attempting to step into an MFC Framework function, e.g. CWinApp::InitInstance, the debugger simply steps over.

Step into MFC Framework failed
Step into MFC Framework failed

Having a look into Output window, we may discover a message like this: “…’C:\Windows\System32\mfc140ud.dll’. Cannot find or open the PDB file”. That’s clear, the necessary PDB file is missing. What can we do? We can buy one from Microsoft or get a free copy from Torrents site. 🙂 Well, don’t need to do that, I was just joking. We can easily get it from Microsoft Symbol Servers, using Visual Studio. Here are the steps:

Changing Debugging/Symbols options in Visual Studio

  1. Open the Options dialog (choose Tools/Options… menu item).
  2. Expand the tree from the left pane to Debugging/Symbols.
Default debugging symbols options
Default debugging symbols options
  • Under Symbol file (.pdb) locations, check Microsoft Symbol Servers. In this moment a message box appears; it suggest that we can choose to get only the debugging symbols for modules which we want, e.g. mfc140ud.dll…
    • Debug performance message
    Debug performance message
  • …so let’s check Only specified modules, then click on Specify modules link and add mfc140ud.dll to the list.
    • Symbols to load automatically
    Symbols to load automatically
  • Type or browse for a folder for caching the symbols, e.g. C:\Symbols . Here is how the debugging symbols options finally looks.
    • Debugging symbols options
    Debugging symbols options
  • Hit OK to close the Options dialog.

    • Notes

    • The same steps can be applied for Visual Studio 2013, except that it needs the symbols for mfc120ud.dll.
    • First time the PDB file is needed it may take a pretty long time for downloading. However, next times it is taken from the cache folder, so symbol loading time becomes irrelevant.
    • If have Visual Studio 2015 with at least Update 1, still may not step into the MFC code, even the symbols has been successfully loaded. For this issue see the next topic.

    Changing Linker/Debugging project properties

    The Update 1 for Visual Studio 2015 comes with /DEBUG:FASTLINK liker option. That’s pretty cool for improving link times but unfortunately, if it’s set, it makes not possible stepping into the MFC Framework code, although the necessary symbols has been loaded. So let’s change it, following these steps:

    1. Open the project’s Property Pages.
    2. Choose Debug configuration and All Platforms.
    3. Expand the tree from left pane to Configuration Properties/Linker/Debugging.
    4. Change Generate Debug Info option from Optimize for faster linking, (/DEBUG:FASTLINK) to Optimize for debugging (/DEBUG).
    Optimize for debugging
    Optimize for debugging
  • Hit OK to close project’s Property Pages.

    • Notes

    • The above option can also be changed for all projects in the Property Manager window.

    Resources and related articles

    by Marius Bancila

    Debugging Tips: Memory Leaks Isolation

    In a recent post we showed how to detect memory leaks in MFC. In this post we present some tips for breaking on a particular allocation that leaks. However, you must note that this technique only works if you are able to find a reproducible allocation, with the same number.

    Here is a memory leak report:

    Detected memory leaks!
Dumping objects ->
{183} normal block at 0x0036B320, 128 bytes long.
 Data:  42 61 62 61 20 53 61 66 74 61 00 CD CD CD CD CD 
Object dump complete.
The program '[1758] MyTest.exe: Native' has exited with code 0 (0x0).

    The allocation number is showed in curly brackets {}, and in this case was 183.

    The steps to be able to break when an allocation that leaks is created are:

    • Make sure you have the adequate reporting mode for memory leaks (see Finding Memory Leaks Using the CRT Library).
    • Run the program several times until you find reproducible allocation numbers ({183} in the 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 (in my example it would be 183).
    • 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.