Cannot get Remote Debugging working with VS2010

Question

I have a server and a workstation on the same corporate domain. My user is a local administrator on both machines. I have Installed the VS2010 version of MSVSMON and set it to run as a service on the server under my user DOMAIN\greg.b (I gave myself "log on as service"). I log onto the server using my domain account and start Remote Debug monitor. I then connect to the server from my Visual Studio. In the monitor on the server I can see

23/09/2010 16:26:33 DOMAIN\greg.b connected.

Then a moment later, I get a dialog from Visual Studio saying

Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'SERVER_NAME'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. A firewall may be preventing communication via DCOM to the local computer.

I've got the DCOM ports open (TCP 135) on both my workstation and server as detailed here.
I have tried it with the Windows Firewall service turned off.

I'm completely stumped!

The server is running Windows 2003 Standard SP2 32bit running the x86 MSVSMON. My workstation is running Windows 7 Pro 64Bit and VS2010 Pro.

Answer 1

Make sure devenv.exe (visual studio) is in the firewall program exceptions list on the with the DOMAIN checkbox checked!

I was in the same situation, stopped the firewall services running on my machine (win7 x64) but it did not work until I made this change.

Answer 2

I was having the same problem, I was running VS2010 in a VM, I changed networking from NAT to Bridged, could ping 2 ways, and it worked.

Answer 3

In my case : Since the remote machine was not part of the local subnet, I had to go to Windows Firewall -> Advanced Settings -> In bound rules. Select the rule for MS Visual Studio and add remote machine's IP address to "Scope" section. This was in addition to the windows firewall settings described above.

Answer 4

What helped in my case was the following:

Run dcomcnfg.exe on the machine where your VS is, go to:

Component Services -> Computers -> My Computer -> Properties -> COM Security -> Access Permissions -> Edit Limits

You should grant remote access to the ANONYMOUS LOGON.

Don't mess around with the other permissions - could cause you trouble.

Answer 5

I guess there are a million reasons for this problem! I tried all the above answers but nothing worked for me but this: I managed to get it working by disabling the option to use the "managed compatibility mode"

For that, go to the options in VS, like: Tools -> Options -> Debugging -> General -> disable "Use Managed Compatibility Mode"

Answer 6

What solved my problem was this

1. Turn off Native Compatibility Mode and Managed Compatibility Mode.
2. In Visual Studio 2013, turn off Enable native Edit and Continue.

https://msdn.microsoft.com/en-us/library/2dbesfyx.aspx

I also restart the computer (windows basic rule!)

Answer 7

Same problem here. My reason was that Trend network security was enabled in the local computer, and it was blocking the connection. I could not stop it because I needed a password, so I just deleted all the Trend processes, and then it worked fine. So you could check if some antivirus or security service is enabled and could be blocking the access.

Answer 8

I just had this problem (never had this problem previously, I remote debug all the time) and resolved it.

First thing I did was narrow it down to being a problem on my machine. When I disabled my firewall lo and behold things worked again so I knew it was my machine and my firewall.

The msdn page at http://msdn.microsoft.com/en-us/library/ee126350(v=vs.100).aspx says if 'Microsoft Visual Studio' is listed in the firewall list to click 'Allow another program' and select it again.

When I clicked 'Allow another program' a list of applications popped up and but Microsoft Visual Studio was not in THAT list so I browsed to devenv.exe and I got a message that it was already in the list! Fortunately it told me that it thought it was in the list as Microsoft SQL Server Data Tools.

So I removed the entry for 'Microsoft Visual Studio' since apparently the same rule was already in the list but with a different name and viola everything works again.

I'm guessing an update or perhaps my VS 2013 Express install somehow affected the firewall settings and having the rule in there twice was confusing my computer.