Configure Visual Studio 2010 Remote Debugger

Question

I have installed the Visual Studio 2010 Remote Debugger on a Windows Server 2003 (x86) server, and am attempting to connect to it results in the following error:

Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'ServerName'. 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. Please see Help for assistance.

I have checked my Windows firewall setting, and ensured file sharing is enabled on my local machine. I have ensured that DCOM is running on the server, as well as the debugging service. There are no actual firewalls involved that I know of.

What else do I need to change to get this to work?

Answer 1

I just ran into connectivity issue. The problem was the Client PC (my desktop) could connect to Remote Host running debug monitor, but the Remote Host could not send data back to my desktop.

Turns out that it was caused by the 'Profile' setup in Windows Firewall. The Firewall rule was being limited to 'Public' profile - but my desktop was connected to the local domain. Changing the setting to 'Domain' ensured the Remote Host could communicate debugging data back to Client desktop.

Check under Windows Firewall -> Inbound Rules -> Microsoft Visual Studio -> Advanced Tab.

Cheers, J

Answer 2

I am using local DNS so I can test websites before they go live (by editing my hosts file).

I have a specific IP assigned by my router at home and at work.

i.e. dev.example.com is mapped to 192.168.1.123

When my machine changed to a different network without me realizing it could no longer reach the debugger and so I got the error.

Pretty obscure situation I had to get this error, which no amount of rebooting or recycling IIS will fix.

Answer 3

I had the same problems with the debugging service. The debugging service was starting automatically but I could never connect. I even turned off the firewall completely and that didn't help either.

Try running the debugging monitor (as opposed to the service) and connecting to that. You can find it in the start menu.

Confused about the difference between the monitor and the service? So was I. See http://social.msdn.microsoft.com/Forums/en/vsdebug/thread/afc80afc-c8eb-4831-915a-1edb8d188f98

Answer 4

I kept getting the same error listed above, and after trying all of the other answers, the problem turned out to be that DCOM was disabled on my development machine. The problem was solved by enabling DCOM using the instructions from this technet link.

Answer 5

Below is a quick step to set up Visual Studio Remote Debugging Monitor on Visual Studio IDE.

• Open Programs > Microsoft Visual Studio 2010 > Visual Studio Tools > Visual Studio 2010 Remote Debugger Folder.

• A Windows Explorer shows the 32 and 64-bit versions of the Remote Debugging Monitor.

• Copy the respective ver that matches remote server (e.g. x64 machine use X64 folder & x32 machine use X86 folder) to a folder on your machine.

• While at the console on your remote machine, go to the folder and start msvsmon.exe.

• Go to Tools > Options and change the Authentication mode to No Authentication and check the box Allow any user to debug.

• From your development machine, on Visual Studio, go to Tools > Attach to Process.

• Change the Transport to Remote and the Qualifier to the name of your remote server.

• You should now see the executable, which you want to debug on that list. Select the process you want to debug and click Attach.

• You may now debug the code while it is running on the remote server.

• Just remember to turn off Remote Debugging Monitor at the remote server once done.

Please refer below MS link: https://docs.microsoft.com/en-us/visualstudio/debugger/remote-debugging-cpp?view=vs-2017

Answer 6

Same problem here. My reason was that Trend security was enabled in the local computer, and it was blocking the firewall. I could not stop it because I needed a password, so I just deleted all the Trend processes, and it seemed to work fine. So you could check if some antivirus is enabled that is blocking the access.

I also needed to add devenv.exe to the Allowed Programs in the Windows Firewall in the local computer, and set its policies.