Saturday, April 21, 2007

Symbols for CRT and MFC Source Code

[12/19/2014: Updated to include Visual Studio 2013.]

I'm not sure why I keep getting stuck on the littlest things. Ever since I installed Visual Studio 2010, I haven't been able to debug into the C Runtime (CRT) or the MFC source code. This is an operation that never gave me any difficulties in years of using VC6, so it's been quite frustrating. I've made several attempts to fix the problem, but no success until today.

Reproducing the problem is straightforward. Set a breakpoint in one of your MFC message handler functions, go to the Call Stack window, and try to click on any of the functions in mfc80d.dll. Similarly, any attempt to set a breakpoint on an MFC function (such as CWinApp::CWinApp) simply fails to work.

Part 1

If you look at the Output window, you'll see a message such as this one:

'MyApp.exe': Loaded 'C:\WINDOWS\WinSxS\x86_microsoft.vc80.debugmfc_1fc8b3b9a1e18e3b_8.0.50727.762_none_29a8a38855141f6e\mfc80d.dll', Symbols loaded (source information stripped).

The key part is "source information stripped", which is strange, because the PDB files for MFC ship with Visual Studio (and the service pack) and those PDB files include source information.

I searched my system for mfc80d.pdb and I found two copies. The first copy is in the symbol cache at c:\cache\mfc80d.i386.pdb\A12C75C3E6A244E3B3BFBE577AB27642e. This file was about 2MB. The second copy of mfc80d.pdb was in c:\windows\symbols\dll. This file was 13.5MB, significantly larger and probably the version of the PDB file that I needed. The problem was making VC2005 use it. That's the hard part.

First go to Tools/Options, open Debugging, and select Symbols. Add the directory "C:\Windows\Symbols\dll" to the beginning of the list. This is different than how VC6 was configured, which required that you not include the "dll" part of the path.

Click OK. Now close Visual Studio. Go to Task Manager and make sure its gone. Now kill the process MSPDBSRV.EXE, if it's running.

Finally, the critical operation to making all of the other steps work is to remove the smaller copy of mfc80d.pdb from the cache. To do this, delete the directory c:\cache\mfc80d.i386.pdb. The path may be slightly different if you are on a 64-bit system.

At this point you can restart VC2005, load your project, and run your application. In the Modules window, you should see that the symbol file for mfc80d.dll is being loaded from C:\Windows\Symbols\dll.

Part 2

[This applies to Visual Studio 2010, 2012, and 2013.]

You may need to tell Visual Studio where the source code is installed. Right-click on a C++ solution and select Properties. Under Common Properties, select Debug Source Files. For Visual Studio 2013, it looks like this on my machine:

Problem solved.


6 comments:

  1. I've looked all over the Internet for this solution.

    Thank you!!

    ReplyDelete
  2. Still helpful in 2012 with VS2010. Thanks.

    Note VS2010's default symbol cache path is %userprofile%\AppData\Local\Temp\SymbolCache

    ReplyDelete
  3. I seem to have problems getting DrWatson to use the correct MFC100.DLL file too.

    Is there a corresponding fix for that?

    ReplyDelete
  4. I haven't used DrWatson in forever, but the fix should be the same, except that I don't know the registry location that Dr Watson uses to search for symbols.

    ReplyDelete
  5. I am using VS 2015 and I am also unable to step into MFC source code. For VS 2015 my C:\Windows\symbols\dll has no MFC files. And Tools/Options, Debugging, Symbols, does not allow me to reorder the items but I assume that would make no difference since C:\Windows\symbols\dll has no MFC files.

    My AppData\Local\Temp\SymbolCache has folders for mfc140d.i386.pdb and mfc140ud.i386.pdb and I assume they are the relevant items.

    ReplyDelete