none
VS2012 Update 3 breaks debugging with MFC110d.pdb RRS feed

  • Question

  • I recently applied the release candidate for VS2012 Update 3 (download from Microsoft as VS2012.3 RC.exe) to fix bug 772859 (see //connect.microsoft.com/VisualStudio/SearchResults.aspx?SearchQuery=772859).

    Our problem (OnInitDialog() called twice when EndDialog() called in there) is solved by this, but since that Update I can not debug into MFC sources via MFC110d.pdb any more as if there are no symbols available. When starting a debug session, the Output window states:

    Loaded 'C:\Windows\SysWOW64\mfc110d.dll', Symbols loaded (source information stripped).

    but when i try to debug into any code of mfc110d.dll it ends up in a window with title 'Source Not Available'. When I look into the 'Symbol Load Information' (context menu in 'Call Stack' window) I see:

    C:\Windows\SysWOW64\mfc110d.i386.pdb: Cannot find or open the PDB file.
    T:\Microsoft\VisualStudio11.0\Common7\IDE\mfc110d.i386.pdb: Cannot find or open the PDB file.
    C:\Users\temmink_ax\AppData\Local\Temp\SymbolCache\MicrosoftPublicSymbols\mfc110d.i386.pdb\9D0F56C2D65D47B0819267146C60B56A17\mfc110d.i386.pdb: Symbols loaded.
    Symbols loaded (source information stripped).

    Although an appropriate pdb file apparently was found in the 'MicrosoftPublicSymbols' cache (My 'Symbol Settings' are set to load automatically from Microsoft Symbol Servers) I do not see any MFC source code to debug into. I also deleted the cached pdb file and re-loaded it from the Symbol Server but without effect.

    Did anybody using VS2012 Update 3 RC recognize such behaviour already?

    Is there any remedy or did Microsoft not (yet) provide a matching pdb file since that update is still a release candidate?

    • Moved by Ego Jiang Friday, June 14, 2013 7:44 AM
    Thursday, June 13, 2013 8:36 AM

Answers

  • Can you try setting the symbol path to C:\Windows\Symbols\dll. That's where the private symbols for Visual C++ libraries are stored, its automatically updated based on the updates you install.

    The ones in public symbol server are public symbols hence you won't get source information.

    Let us know if this works!


    Blog: http://ntcoder.com/bab


    Posts are provided as is without warranties or guaranties.

    • Marked as answer by AxelTe Friday, June 14, 2013 5:13 PM
    Friday, June 14, 2013 12:17 PM
    Moderator

All replies

  • Hi,

    Welcome here.

    Please try to post your issue with a reproducible sample code at http://connect.microsoft.com/VisualStudio/

    Have a nice day.

    Regards,


    Elegentin Xie
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Friday, June 14, 2013 7:45 AM
    Moderator
  • Can you try setting the symbol path to C:\Windows\Symbols\dll. That's where the private symbols for Visual C++ libraries are stored, its automatically updated based on the updates you install.

    The ones in public symbol server are public symbols hence you won't get source information.

    Let us know if this works!


    Blog: http://ntcoder.com/bab


    Posts are provided as is without warranties or guaranties.

    • Marked as answer by AxelTe Friday, June 14, 2013 5:13 PM
    Friday, June 14, 2013 12:17 PM
    Moderator
  • Yeah!!! - That was the remedy.

    Thanks a lot for this helpful tip. I unchecked the 'Public Symbol Server', added the path you proposed, emptied the cache and voila - I see the (correct - Update 3) sources for mfc110d.dll when debugging again!

    Friday, June 14, 2013 5:16 PM
  • The reason why private symbols (IMO) are not on public symbol server is because mostly developers are the ones who will need the private symbols for debugging purpose and most of the developers will have Visual Studio installed on their box so they should have that folder created with symbols in it. This way we'll be able to save some bandwidth and time as well since the private symbols come to around 36 MB while public symbols will have much lesser size so downloading them will be much faster.

    For most purposes public symbols should suffice, for e.g. when reporting a crash or checking the call stack etc.


    Blog: http://ntcoder.com/bab


    Posts are provided as is without warranties or guaranties.


    Saturday, June 15, 2013 3:11 PM
    Moderator