Hang loading rasapi32.pdb when using symbol server - by Kevin Puetz

Status : 

  External<br /><br />
		This item may be valid but belongs to an external system out of the direct control of this product team.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 422970 Comments
Status Closed Workarounds
Type Bug Repros 6
Opened 3/12/2009 11:38:24 AM
Access Restriction Public


When running one of our components in the visual studio debugger, the symbol server hangs downloading rasapi32.pdb. The problem seems to occur when our component is loading the WebBrowser control. We started seeing this hang after upgrading to Windows XP SP3, though I think that's a red herring and the SP simply upgraded some DLLs that now need new symbols. There also needs to be some content in the control (about:blank doesn't trigger the problem) to get a hang, but again I think that's just because one has to get IE to load some DLLs I don't already have symbols cached for.

I believe this is the same problem that Steven Wilssen replied to at http://social.msdn.microsoft.com/Forums/en-US/refsourceserver/thread/26a4b712-6c82-4627-90f8-7188c7ebab10/, where he indicated he was seeking a repro case for this. However, my attempt to contact him bounced with "Recipient address rejected: Access denied"

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.
Sign in to post a comment.
Posted by Bjoahl on 6/14/2012 at 1:26 AM
No fix yet, Win7, VS2010...
Posted by WithinRafael on 7/17/2010 at 7:25 PM
Experienced this issue with a CLI app., symchk'ed entirety of \SysWow64 and \System32 to workaround.
Posted by Microsoft on 3/17/2009 at 4:03 PM
Hello Kevin,

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.

Best Regards,
Andrew Hall
Visual Studio Debugger
Posted by Microsoft on 3/13/2009 at 2:05 AM
Thanks for your feedback.

We are escalating this issue to the appropriate group within the Visual Studio Product Team for triage and resolution. These specialized experts will follow-up with your issue.

Thank you,
Visual Studio Product Team