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.