Cannot start or attach debugger: the remote endpoint was not reachable - by Skomialek

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<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 760468 Comments
Status Closed Workarounds
Type Bug Repros 12
Opened 8/30/2012 2:48:19 PM
Access Restriction Public



This problem has already been reported and closed as fixed here : 

Unfortunately this problem still occurs in VS 2012 RTM (.Net 4 project, x64 configuration)

My system configuration is : Windows 8 Pro RTM + VS 2012 RTM

What I've noticed is that this bug might have something to do with Cisco VPN client (running Cisco AnyConnect VPN Client Version 2.5.2001)

Whenever I connect to the corporate VPN I seem to be getting the error. It occurs until I restart the machine. After rebooting everything goes back to normal.


If I start VPN connection during the debugging session running I get VS to show dialog saying : "Remote operation takes longer than expected" followed by message box with error "The debugger's worker process (msvsmon.exe) unexpectedly exited. Debugging will be aborted.". When I try to start debugging again I get the error mentioned before. ("Cannot start or attach debugger...")

Sign in to post a comment.
Posted by Raz0rBlack on 8/24/2015 at 1:57 PM
I found this thread while searching for this error message. Curiously, this suddenly started in Visual Studio 2015 RTM on a Windows 10 RTM machine, but Visual Studio 2013 with Update 4 doesn't have this issue, even on the same project. A simple solution with the basic MCV template triggers this behaviour. After setting the used application pool to accept 32 bit applications, the message in VS 2015 disappeares and the process seems to hang. Resetting the application pool setting to FALSE gives the same message (A 64-bit debugging operation is taking longer than expected.)
Posted by Jimmee on 2/14/2014 at 2:19 PM
My company has changed VPN clients and no longer using Avaya (Nortel) Extrannet.
Happy to report that VS 2012 Update 4 is working with Cisco AnyConnect v3.1.02026.
Posted by Jimmee on 3/22/2013 at 2:51 PM
Setting the app pool to ‘Enable 32-bit applications’ to ‘true’ allows debugging with VPN active, however, start and stop of debugging is very slow. Often see the "...taking longer than expected..." message flash on screen. I do not see the unable to attache to end point message when debugging fails as debug fails early in start up. I have also see debugger fail to start when attempting to start simple console application.

Visual Studio Ultimate 2012, Version 11.0.51106.01 Update 1.
Windows 7 Ultimate 64bit Service Pack 1, all Windows updates applied.
Avaya VPN Client v10.04.108 64bit

Posted by Marc [MSFT] on 2/1/2013 at 4:06 PM
Thanks Marek for the details.

This is a case of Avaya completely blocking our connection. That's why we can't even tell if the process is managed or not in the w3wp attach case you mentioned. I believe that WebApp projects always target x64 wherease iisexpress is always x86. You will only see this for x64 debugging scenarios. We need to create a fake remote connection via msvsmon for x64 scenarios in order to talk to a an x64 process from VS which is running 32bit. To work around this for your webapp, you'll have to change your application pool settings.

1.    Start IIS manager
2.    Navigate to ‘Application Pools’
3.    Select the application pool that your app is running in
4.    Right click and bring up ‘Advanced Settings’ for this app pool
5.    Change ‘Enable 32-bit applications’ to ‘true’

Additionally, I've send an email to Avaya to let them know that they have a compatability problem. I don't know when they'll be able to provide a fix but at least they know there is an issue now.

I hope this information helps. Thanks for reporting it.

Posted by Marek W on 1/29/2013 at 5:37 PM
Hello Marc,

I do not see the message you've mentioned on your post.

Regardless of the target of my WebApp project, either AnyCPU (my default), x86 and x64, in all cases the experience is the same while on Avaya VPN.

Debugging does not hang, here’s what happens.

- WebApp project is setup to run using Local IIS Web Server. The problem does NOT happen if I use IIS Express, but then I have other issues with my projects where I need full IIS. As far as I can tell, MSVSMON.EXE is not used to debug IIS Express.

- F5 to start debugging.

- The first time, after several seconds of wait, I get a progress dialog indicating the following information:
Title: Operation taking longer than expected
Message: A 64-bit debugging operation is taking longer than expected. This may be caused by incompatibilities with 3rd party networking software. Link: See help for troubleshooting these issues.

- Next and any subsequent attempt to debug the following error message appears.
Title: Microsoft Visual Studio
Message: Unable to start debugging on the web server. The Microsoft Visual Studio Remote Debugging Monitor (MSVSMON.EXE) does not appear to be running on the remote computer. This may be because a firewall is preventing communication to the remote computer. Please see Help for assistance on configuring remote debugging.

If I watch Task Manager while I attempt to debug, I do see MSVSMON.EXE start for a few seconds, then it ends. I've searched in my Event Logs but I don't see anything logged in there. I was hoping to find something logged by MSVSMON.EXE there.

One last thing, which I don’t know if it’s relevant or not. When on Avaya and this problem is happening, the w3wp.exe worker process shown in the “Attach to Process” dialog in Visual Studio appears as Type=x64. When I am not on Avaya VPN and everything works OK, the w3wp.exe process appears as Type=Managed(v4.0.30319), x64.

If there's anything else I can do to help research this, please let me know.

Posted by Marc [MSFT] on 1/25/2013 at 4:47 PM
Hey Marek/Jimee, are specifically seeing the message "the remote endpoint was not reachable"? I want to confirm the exact behavior as we've had reports from some people that with certain VPNs, the debugging would simply hang. In these cases, we had to get the issue fixed by the third party VPN vendor as we were not able to fix it ourselves.

Does targetting the x86 configuration work for both of you?

Once I have the details, I can reach out to Avaya and ask them to investigate. Thanks.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Marek W on 1/25/2013 at 4:32 PM
I too have this same problem with the Avaya VPN Client, in my case v10.5.150.0 and confirmed with another colleague. I realize this case is Closed as Fixed by Update 1, which may be the case for other VPN software but not yet for Avaya. Fortunately I have access to a different VPN client, Aruba, where this problem does not occur.

I just wanted to post this here, hoping that this error can be made more prominent for other users to find the solution (i.e. get another VPN client if you use Avaya). We spent countless hours researching this problem and it wasn't until we tied the issue to our VPN connection, when a search for "Visual Studio 2012 debug VPN" brings up this thread into the first matches.

All in all, thank you for this post as it helped us confirm the issue and seek an alternative.

For reference:
Visual Studio 2012 Ultimate Update 1
Windows 7 Enterprise 64bit
Posted by Jimmee on 12/6/2012 at 1:46 PM
I still have this problem after applying VS 2012 Update 1.
Avaya VPN Client v10.04.108 (Previously know as Nortel Network's Extranet VPN Client)
Workaround #1 works for me, however, I'm a telecomuter and no VPN means no connection to TFS. :-(
Posted by Marc [MSFT] on 10/29/2012 at 4:15 PM
Hello, please try the final CTP for VSUpdate 1 and let us know if that does not resolve this issue:

This update includes our workaround for this issue.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Scott Koland on 10/19/2012 at 9:34 AM
Updating my Cisco AnyConnect client to 3.1 fixed this issue for me. Though I was able to get version 2.5.x to work on Windows 8, it is not officially supported and I also ran into other issues using 2.5 which required the update to 3.1.

With gratitude,
Posted by Gregg [MSFT] on 10/16/2012 at 4:34 PM
I would like to thank everyone who helped to bring this issue to our attention and helped us to troubleshoot the issue. We now have a fix for the issue, and we expect to ship this fix as part of an upcoming update to Visual Studio 2012. Unfortunately because of the nature of the problem where various 3rd party networking software causes the problem, it is impossible to say that in all cases that this fix will fully resolve the problem. But we have received confirmation from some users that the fix worked for them, and we hope it will resolve the problem for everyone facing this issue.

Thanks again for all the help,
Gregg Miskelly
Visual Studio Debugger developer
Posted by Marc [MSFT] on 10/9/2012 at 5:42 PM
It may be that whatever you have running is blocking our IPv6 connection for some reason. We don't have a good list of what's impacting us but we are looking for workarounds. We were working with one customer to try to detect when our connection is blocked and revert back to IPv4 as we think that should fix most of these cases but he stopped responding.

If anyone on this bug is willing to try out a small utility we've created to test our logic for detecting that debugging has been blocked, please email me at and I can send you the app. That would help us out a lot since we don't have access to most of these 3rd party software applications.

As Scott noted, disconnecting from the VPN often seems to fix the problem as well as trying to uninstall the software (if you can determine which one it is).

Marc Paine
Visual Studio Debugger QA Lead
Posted by Scott Koland on 10/8/2012 at 9:48 AM
I have the same issue with Windows 8 Pro RTM & VS 2012 RTM. I never had the VS 11 beta or VS 2012 Previews installed on this machine. My Cisco AnyConnect VPN Client version is 2.5.2019.0.

I did not install ContentWatch IE filter, and I don't see any such program listed in IE settings or Control Panel. The disconnected from VPN workaround works for me.
Posted by Skomialek on 9/18/2012 at 12:19 PM

If this is a third party product then I rather don't have it installed on my machine (as long as it didn't install as some kind of freeware thing).

if it helps I use AVG Internet Security as my FW & AV package. (2013 Beta version for Windows 8)

Posted by Marc [MSFT] on 9/18/2012 at 10:53 AM
Thanks all for the additional comments.

By any chance, do any of your have ContentWatch IE filter enabled? We've been working with a customer who was having similar issues debugging with their VPN but it turned out it was the ContentWatch filter and uninstalling that fixed the problem rather than the VPN software.

Please try that out and let us know.

Marc Paine
Visual Studio Debugger QA Lead
Posted by Cor Kroon on 9/12/2012 at 3:04 AM
I can reproduce this error 100%. Without VPN debugging works fine. When connecting to the company VPN with Cisco AnyConnect VPN Client Version 2.5.2017, I get the same error message. A restart and running VS 2012 without VPN seems to be the only possible workaround that works.
Posted by Sean Lavies on 9/4/2012 at 5:45 AM
I am also having the exact same issue. I have to use VPN frequently and a reboot is the only way I have found to fix the issue.

Windows 7 Enterprise
Ciso AnyConnect VPN 2.5.2017
VS 2012 RTM
Posted by Bob Sarrett on 8/31/2012 at 3:55 PM
I am experiencing the same issue. I am running Windows 7 Enterprise 64 bit and VS 2012 RTM. I also have Cisco AnyConnect VPN 2.5.0217. The application is .Net 3.5 project, Any CPU configuration.
Posted by Skomialek on 8/31/2012 at 12:32 PM
Any results of your trial with VPN client, I'm not 100% sure it's caused by it but it really looks like it is the reason.
Posted by arhoads76 on 8/31/2012 at 6:00 AM
I get this error too. I hadn't noticed a correlation with Cisco VPN client, but I do have it on my machine. I do not typically have it running, but will try rebooting and trying to attach the debugger before starting the VPN client once.
Posted by Microsoft on 8/30/2012 at 9:32 PM
Thanks for your feedback.

We are rerouting 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.
Posted by Microsoft on 8/30/2012 at 2:51 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(