Fixing “The network connection to [My Computer] has been lost. Debugging will be aborted.”

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:

Image of "The network connection to [My Computer] has been lost. Debugging will be aborted."

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:, 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:

image of Debug settings

Et voilà! I could debug again!

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

devenv /ResetSettings

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.


, , , ,

  1. #1 by Roberto Francisco on November 6, 2015 - 12:44 pm

    Amazing, good job buddy!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: