Answered by:
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.
- Edited by Xiaoyun Li – MSFT Tuesday, September 16, 2008 10:09 AM edit
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.- Marked as answer by Xiaoyun Li – MSFT 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.- Marked as answer by Xiaoyun Li – MSFT 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. -
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...)