none
KB951336: VS Debugger seems to hang when you start debugging

    Question

  • KNOWLEDGE BASE SOLUTIONS 

    KNOWLEDGE BASE SOLUTIONS PROVIDE INFORMATION DIRECTLY FROM WITHIN THE MICROSOFT SUPPORT ORGANIZATION. THE INFORMATION CONTAINED HEREIN IS CREATED IN RESPONSE TO EMERGING OR UNIQUE TOPICS, OR IS INTENDED SUPPLEMENT OTHER KNOWLEDGE BASE INFORMATION.


    Link to Original Article from Microsoft Support

    VS Debugger seems to hang when you start debugging

    Action

    Create a simple MFC application in Visual Studio 2003 / 2005/ 2008. Start debugging by pressing F5.

    Result

    Visual Studio debugger takes a long time to start debugging the application.  This gives an impression that Visual Studio has hung.

    Thursday, August 28, 2008 2:53 AM

Answers

  • Cause
    Invalid symbol path location, or a geographically distant location where symbols are stored, causing high network latency.

    Resolution

    Check if the _NT_SYMBOL_PATH environment variable contains valid information.

    In the Visual Studio IDE, goto Tools->Options->Debugging->Symbols->Symbol File (.pdb) locations. Check if you have valid path here.

    If you do have a valid path in either of these locations, try removing these entries to see if that helps.  If the problem goes away, then you may have a high network latency causing delayed load of symbols and slow debugger startup/response times.

    More Information

    When the debugger starts up, it tries to load the PDB symbol files for loaded modules.  High network latency can cause Visual Studio to become unresponsive.  A local symbol cache can be used to work around the problem.

    DISCLAIMER

    MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

    TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.

    Thursday, August 28, 2008 3:00 AM

All replies

  • Cause
    Invalid symbol path location, or a geographically distant location where symbols are stored, causing high network latency.

    Resolution

    Check if the _NT_SYMBOL_PATH environment variable contains valid information.

    In the Visual Studio IDE, goto Tools->Options->Debugging->Symbols->Symbol File (.pdb) locations. Check if you have valid path here.

    If you do have a valid path in either of these locations, try removing these entries to see if that helps.  If the problem goes away, then you may have a high network latency causing delayed load of symbols and slow debugger startup/response times.

    More Information

    When the debugger starts up, it tries to load the PDB symbol files for loaded modules.  High network latency can cause Visual Studio to become unresponsive.  A local symbol cache can be used to work around the problem.

    DISCLAIMER

    MICROSOFT AND/OR ITS SUPPLIERS MAKE NO REPRESENTATIONS OR WARRANTIES ABOUT THE SUITABILITY, RELIABILITY OR ACCURACY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE (THE “MATERIALS”) FOR ANY PURPOSE. THE MATERIALS MAY INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS AND MAY BE REVISED AT ANY TIME WITHOUT NOTICE.

    TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, MICROSOFT AND/OR ITS SUPPLIERS DISCLAIM AND EXCLUDE ALL REPRESENTATIONS, WARRANTIES, AND CONDITIONS WHETHER EXPRESS, IMPLIED OR STATUTORY, INCLUDING BUT NOT LIMITED TO REPRESENTATIONS, WARRANTIES, OR CONDITIONS OF TITLE, NON INFRINGEMENT, SATISFACTORY CONDITION OR QUALITY, MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WITH RESPECT TO THE MATERIALS.

    Thursday, August 28, 2008 3:00 AM
  • I am experiencing similar symptoms with Visual Studio 2008 SP1 on Vista SP1 while debugging a medium-sized native C++ app using large-ish custom libs, however I believe it is caused by a completely unrelated problem. (I use the MS Symbol Server, and already have a symbol cache set up. No latency problems whatsoever.)
    When I hit F5, the Visual Studio GUI rearranges itself for Debug Mode, and then the whole interface becomes unresponsive for several seconds (up to 10 or 20, depending). During this time CPU usage increases significantly - VS is clearly crunching. Then, the interface becomes responsive again and the debugger starts properly, outputing module & symbol loading information to the Output window.
    From my experimentation so far, it has to do with the number of breakpoints set, and perhaps the size of the codebase.
    Basically, if you have none (or one, for testing) breakpoints set, then this start-up delay does not occur.
    However, if you even have a handful of breakpoints set, then VS 2008 spends a significant amount of time churning. I used Process Monitor and discovered that it reads from *many* source files, and PDBs, during this phase. (The stack time breakdown for the entire start-up process indicates that almost 50% of this time is spent in GetFileAttributes - this includes the symbols loading phase though.)
    If I was to hazard a guess, VS is churning while its breakpoint handling/resolution code is attempting to assign each one. What I don't understand is why is this a new 'feature' of VS 2008 when Visual Studio 2005 had none of these problems?
    I believe this whole problem is also related to why single-stepping performance in native code can be so poor. Not only is each step slow, but the caret in the source editor visibly lags behind the yellow 'current statement' arrow. The more breakpoints I have enabled, the slower each step is. It can become very frustrating, especially when single-stepping in VS 2005 was normal (i.e. fast). I have closed all debugger-related windows to no avail - is has no significant impact on single-step delays.
    I am trying to re-open this issue on MS Connect. Please see https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=346170 for more details.
    Saturday, October 03, 2009 3:51 AM
  • I just finished performing a side-by-side comparison of the debugger start-up sequence in Process Monitor - one with break-points, the other without any.
    The traces are almost identical (certain files are read in a different order, etc), however there is a noticable time-lag that slowly accumulates in the trace with break-points.
    It appears that when the GUI becomes unresponsive, the start-up sequence is actually still proceeding as normal: each DLL that is referenced by the EXE is loaded, symbols located, etc.
    When normal (system) DLLs are encountered, their load times are roughly equal between traces. However, when custom (my own) DLLs are loaded, there is a significant (half-a-second) latency between two consecutive NatDbgDEUI.dll events. For all standard system DLLs, the delay was insignificant. I thought it might be because of dynamic relocation (I haven't rebased my DLLs) however the delay also exists for the first of my DLLs, which isn't relocated - so it can't be that.
    Then I had a look at the Modules list and saw that the only DLLs for which full symbols had been completely load (i.e. DLLs with accompanying source/debug info) were my DLLs, and the debug versions of the MFC/CRT DLLs. Closer inspection reveals that the delays creep in between the following two calls (top kernel calls have been deleted):

    1) Closing the DLL that is currently being processed:

    13    kernel32.dll    CloseHandle + 0x40    0x7653cc2e    C:\Windows\system32\kernel32.dll
    14    NatDbgDE.dll    NatDbgDE.dll + 0x1bd73    0x6123bd73    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    15    NatDbgDE.dll    NatDbgDE.dll + 0x1d4b2    0x6123d4b2    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    16    NatDbgDE.dll    NatDbgDE.dll + 0x1d5e5    0x6123d5e5    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    17    NatDbgDE.dll    NatDbgDE.dll + 0x1a382    0x6123a382    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    18    NatDbgDE.dll    NatDbgDE.dll + 0x1a426    0x6123a426    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    19    NatDbgDE.dll    NatDbgDE.dll + 0x1a491    0x6123a491    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    20    NatDbgDE.dll    NatDbgDE.dll + 0x1a551    0x6123a551    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    21    NatDbgDE.dll    NatDbgDE.dll + 0x19e75    0x61239e75    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    22    NatDbgDE.dll    NatDbgDE.dll + 0x19dae    0x61239dae    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    23    NatDbgDE.dll    NatDbgDE.dll + 0x19739    0x61239739    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    24    NatDbgDE.dll    NatDbgDE.dll + 0xb707    0x6122b707    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    25    NatDbgDE.dll    NatDbgDE.dll + 0xb672    0x6122b672    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    26    NatDbgDE.dll    NatDbgDE.dll + 0x19651    0x61239651    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    27    NatDbgDE.dll    NatDbgDE.dll + 0xb5f4    0x6122b5f4    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    28    NatDbgDE.dll    NatDbgDE.dll + 0xb881    0x6122b881    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    29    NatDbgDE.dll    NatDbgDE.dll + 0xb548    0x6122b548    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    30    NatDbgDE.dll    NatDbgDE.dll + 0xdfd5    0x6122dfd5    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    31    NatDbgDE.dll    NatDbgDE.dll + 0xde6b    0x6122de6b    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    32    NatDbgDE.dll    NatDbgDE.dll + 0xe229    0x6122e229    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    33    NatDbgDE.dll    NatDbgDE.dll + 0x1c619    0x6123c619    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    34    NatDbgDE.dll    NatDbgDE.dll + 0xdf99    0x6122df99    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    35    NatDbgDE.dll    NatDbgDE.dll + 0xdfbc    0x6122dfbc    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    36    kernel32.dll    BaseThreadInitThunk + 0xe    0x76534911    C:\Windows\system32\kernel32.dll
    37    ntdll.dll    __RtlUserThreadStart + 0x23    0x778ae4b6    C:\Windows\System32\ntdll.dll
    38    ntdll.dll    _RtlUserThreadStart + 0x1b    0x778ae489    C:\Windows\System32\ntdll.dll

    2) QueryNameInformationFile of NatDbgDEUI.dll

    13    kernel32.dll    FSPErrorMessages::CMessageMapper::GetModuleFileNameFromHandleNoLock + 0x7e    0x765123f3    C:\Windows\system32\kernel32.dll
    14    kernel32.dll    FSPErrorMessages::CMessageMapper::NotifyLoadStringResource + 0x59    0x765387ec    C:\Windows\system32\kernel32.dll
    15    kernel32.dll    RealWerpNotifyLoadStringResourceEx + 0x27    0x76538783    C:\Windows\system32\kernel32.dll
    16    kernel32.dll    RealWerpNotifyLoadStringResource + 0x21    0x76538747    C:\Windows\system32\kernel32.dll
    17    kernel32.dll    LoadStringBaseExW + 0x9f    0x7653870d    C:\Windows\system32\kernel32.dll
    18    USER32.dll    LoadStringW + 0x19    0x77709614    C:\Windows\system32\USER32.dll
    19    NatDbgDE.dll    NatDbgDE.dll + 0x5529    0x61225529    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    20    NatDbgDE.dll    NatDbgDE.dll + 0x5576    0x61225576    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    21    NatDbgDE.dll    DllGetClassObject + 0xb158    0x6124f5fe    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    22    NatDbgDE.dll    DllGetClassObject + 0x52da    0x61249780    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    23    NatDbgDE.dll    DllGetClassObject + 0x53d6    0x6124987c    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    24    NatDbgDE.dll    DllGetClassObject + 0xacd4    0x6124f17a    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    25    NatDbgDE.dll    NatDbgDE.dll + 0x1bf1e    0x6123bf1e    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    26    NatDbgDE.dll    NatDbgDE.dll + 0x1c036    0x6123c036    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    27    NatDbgDE.dll    NatDbgDE.dll + 0x197a0    0x612397a0    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    28    NatDbgDE.dll    NatDbgDE.dll + 0xb707    0x6122b707    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    29    NatDbgDE.dll    NatDbgDE.dll + 0xb672    0x6122b672    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    30    NatDbgDE.dll    NatDbgDE.dll + 0x19651    0x61239651    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    31    NatDbgDE.dll    NatDbgDE.dll + 0xb5f4    0x6122b5f4    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    32    NatDbgDE.dll    NatDbgDE.dll + 0xb881    0x6122b881    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    33    NatDbgDE.dll    NatDbgDE.dll + 0xb548    0x6122b548    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    34    NatDbgDE.dll    NatDbgDE.dll + 0xdfd5    0x6122dfd5    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    35    NatDbgDE.dll    NatDbgDE.dll + 0xde6b    0x6122de6b    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    36    NatDbgDE.dll    NatDbgDE.dll + 0xe229    0x6122e229    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    37    NatDbgDE.dll    NatDbgDE.dll + 0x1c619    0x6123c619    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    38    NatDbgDE.dll    NatDbgDE.dll + 0xdf99    0x6122df99    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    39    NatDbgDE.dll    NatDbgDE.dll + 0xdfbc    0x6122dfbc    C:\Program Files\Microsoft Visual Studio 9.0\Common7\Packages\Debugger\NatDbgDE.dll
    40    kernel32.dll    BaseThreadInitThunk + 0xe    0x76534911    C:\Windows\system32\kernel32.dll
    41    ntdll.dll    __RtlUserThreadStart + 0x23    0x778ae4b6    C:\Windows\System32\ntdll.dll
    42    ntdll.dll    _RtlUserThreadStart + 0x1b    0x778ae489    C:\Windows\System32\ntdll.dll

    Something extra is being calculated between those two calls if the project has break-points AND that DLL has accompanying full symbol info.
    The delays slowly add up, contributing to the slow start - but only if you have break-points!? And only now in VS 2008?

    (UPDATE: I ran the debugger on the release version of the app, compiled against the release version of my DLLs that contained no debug info, and it was still slow to start up...?! In fact, turning off debug info for the EXE made the start-up time even longer. Throughout these tests I have turned off the symbol server and disabled auto-search for local symbol files. Quite bizzare...)
    Saturday, October 03, 2009 5:48 AM