VS2005在調試相應程序時，從微軟Symbols服務器加載rasapi32.dll時死鎖的問題。
解決方法，在Tools->Options->Debugging->Symbols->勾選上Search the above locations only when symbols are loaded manually.
一般出現上述問題是在Symbols Location添加了下載服務器：
http://msdl.microsoft.com/download/symbols
VS2005 freezes when downloading RASAPI32.DLL from symbols server
You might try to replace symsrv.dll used by VS with the one from Debugging Tools package
(it should be copied into <VSInstallDir>/Common7/IDE). Sometimes it helps
(though usually it's a kind of network problem that causes it, not VS or symsrv.dll itself).
http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=422970
My theory is that this is a deadlock in trying to fetch http resources:
1) the embedded is loading a number of helper dlls as it downloads the page content;
2) the symbol server fails to find cached symbols for at least one of these (as in the linked forum post, the one that hangs for me is rasapi32.dll)
3) it then tries to connect to http://msdl.microsoft.com/download/symbols, but ends up waiting for something internal to wininet/urlmon that is already held by the web browser control's incomplete download, which is not making progress because the debugger has stopped the process to load symbols.
4) ...
IE also hangs trying to browse to any site while the machine is in this state, but Firefox still works, so I think it's some sort of system-wide lock in wininet HTTP handling. Lacking much knowledge of wininet internals, that's the best I can do for a theory.
Thank you for taking the time to report this, we believe that you hit the nail on the head:
1) Application being debugged contains web browser control
2) Web browser controls loads rasapi under a system wide lock
3) DllLoad is received by debugger (debuggee is in break mode)
4) Debugger needs to make an internet request to symbol server
5) Wininet needs to take the lock the debuggee already holds in order to talk to the symbol server
Unfortunately there is really nothing the debugger can do about this except block the download for the one binary is loaded under the lock. We believe the better solution is for Windows not load the binary while holding this lock. Since the windows team uses a different bug tracking database than Visual Studio, I am going to resolve this bug as “External” and file a bug against the Windows team.