KNOWLEDGE BASE SOLUTIONS

KNOWLEDGE BASE SOLUTIONSPROVIDE 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.

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.

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.

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.

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...)