Recently I found myself unable to Attach to Process to IIS in Visual Studio 2010 to debug a web application. It would appear to work but then I would see this lovely dialog box:
This was confusing because the blacked-out PC name is my laptop that I was debugging from–I wasn’t using Remote Debugging, as far as I knew.
Turns out that on a 64-bit PC, Visual Studio–which is really a 32-bit program under the hood–pulls some magic in order to debug a 64-bit program. It uses Remote Debugging to connect to 64-bit programs!
Once I knew this I was able to determine that the immediate problem was the Remote Debugging Monitor (msvsmon.exe) repeatedly crashing. I was able to confirm this by seeing multiple instances of the following in the Windows Event Log, under Windows Logs->Applications:
Faulting application name: msvsmon.exe, version: 10.0.40219.1, time stamp: 0x4d5f1476 Faulting module name: SYMSRV.dll, version: 18.104.22.1683, time stamp: 0x4b673674
Next I needed to figure out why msvsmo.exe kept crashing. Googling around soon turned up the culprit. That second line in the Event Log entry above held the key: SYMSRV.DLL must stand for SYMbolSeRveR. I recalled I had been debugging an issue and, suspecting something was going on in the .NET framework code, I had turned on Enable .NET Framework Source Stepping in Options->Debugging->General and checked the Microsoft Symbol Server checkbox in Options->Debugging-Symbols.
The fix was as simple as unchecking Microsoft Symbol Server, then clicking the Empty Symbol Cache button:
Hey, Microsoft: seems like a bug here.
If you have this issue, before trying my fix, do the detective work to make sure your root cause is the same as mine; otherwise it won’t do anything for you. I am no expert on this issue, but if you don’t see entries like mine in your Event Log, you could try the various other fixes I saw mentioned, at your own risk: deleting all breakpoints, resetting Visual Studio (via the
command), Repairing or re-installing Visual Studio, etc.
Hopefully this helps someone out there; it was certainly frustrating trying to Google just the error message, as it turned out to be only a symptom and not the root cause. Nevertheless, it was interesting getting a little peek under the covers of how Visual Studio handles 64-bit debugging.