Hi, I would really appreciate some help with remote debugging. It seems that I have tried everything, with no luck.

I am trying to debug ASP.NET application running on Windows 2003 Server from Windows XP machine running VisualStudio 2005 Pro. I have windows firewall shut off as well as antivirus software on the XP machine.

Both server and client are behind firewalls with the required ports open. I have checked all TCP ports from Server to Client with telnet. I also added DCOM permission limits to allow remote access.

The two machines are on different networks. There is an account that I am using on both machines that has the same username and password. I am putting in the IP of the remote machine in the "Qualifier" field on the "attach to process" dialog. I am running my remote debugger as an application not as a service. I can see in the console on the server that the remote connection was successful. Also if I connect via Remote (Native only with no authentication) mode, I can see all the processes no problem and attach.

This is the message I am getting no matter what "The Microsoft Visual Studio Remote Debugging Monitor on the remote computer cannot connect to the local computer. A firewall may be preventing communication via DCOM to the local computer".

I would really, really appreciate any help. It seems like I tried everything to no avail. I am getting very desperate.

Thanks a lot,

               -- Greg

Try to follow steps from this article:

http://support.microsoft.com/kb/910448/en-us

Greg,

 (1) You should verify the Permissions of your Windows Account in the Remote Box. If the process you are attempting to Debug is running under a different "Account Name" your account must be under the "System Administrators" group in the Remote Box.

 (2) If you have enough permission on the remote box try to run the Remote Debugger as administrator.

check services regarding remote connection say RPC through services.msc

hope this helps

Thanks for your responses, so far nothing helps.

SSA - I saw this already, I am doing exactly what it says with no luck

scil - I am running as Administrator on both boxes. I am able to connect to the remote box just fine, but the remote box can't connect back to the debug client.

kathirvelmm - RPC is started.

The problem, I think, is somewhere on the client box. I do have Windows Firewall disabled and all firewall ports open. Also, "no authentication" mode works just fine both ways. I think something maybe wrong with some permissions ? Any ideas?

Thanks a lot!

Hi,

This error means that the Visual Studio Remote Debugger service is running under a user account that cannot authenticate when it tries to connect to the computer that you are debugging from.

You have create same account on both boxs. Please also make sure the following information:

For more information, see http://msdn.microsoft.com/en-us/library/ms164725.aspx

I look forward to receiving your test results.

Hi Thomas,

      I checked all of this, and all of it is set correctly, but still no dice. I also verified that 100% of the packets from the server are being forwarded to the client, so it being a network issue is rulled out. I also completely disabled the windows firewall service on both machines.

Hi,

Can you please test whether the account can view file shared on each machine?

Please also configure the firewall scope to any computer (not subnet only).

Thanks.

Hi Thomas,

       I'm afraid that this would be too much of a security risk to open all the ports. Insn't there a list of specific ports I can use?

Thanks,

    -- Greg

Hi,

Remote debugging relies on dynamic port numbers, so there is no static list of port numbers to be opened.

You can try to

• Configure machine wide DCOM settings to restrict the range of ports which DCOM uses on both boxes.  http://support.microsoft.com/kb/300083
•  Add ports for the DCOM dynamic ports from http://msdn.microsoft.com/en-us/library/bb385831.aspx

Thanks.

Hey Everyone,

I don't have an answer to Greg's problem because I am faced with a similar issue trying to figure out how to enable remote debugging on a 2003 server inside a DMZ. My note is more a comment/question to the Microsoft architects. 

Why in the world would you configure the remote debugger to use dynamic ports? Don't you know that there are many companies out there that have DMZs and have tight firewall security controls in place? I work for a fortune 500 company, and our network team scrutinizes and checks every firewall request. They would never allow an application to configure the firewall. In fact, I wouldn't even dare ask them because I know I'd be making a fool of myself. I know what their response will be.

So, why don't you modify the remote debugging components to allow for simple port configuration using an INI or a .config file so it's easy to control which port is being used. That would make life simple. wouldn't it?

Thanks,

As much as I hate some of these limitations, I still say:

I_Love_DotNet

Just an update on this issue, I already spent ~ 5hrs with Microsoft Techs remote debugging this issue, and right now waiting for an answer if "it's at all POSSIBLE to remote debug over the internet". You would think that the whole point of "remote debugging" is to debug computers not on the same network. Apparently, it might be impossible by design. Still waiting to hear if this is indeed the case. Extremely frustrating…

Just spoke with Microsoft again, and they said that it is NOT supported to debug over the internet. Due to DCOM issues you can only remote debug within the same domain on the network.

This clearly seems like a huge flaw with remote debugging and a major disadvantage for the majority of the people who have their production enviroment on a different network than development workstations.

Maybe if you can can open communition on all ports between client and server it might be possible, but I have not tried that. Either way, that's not officially supported.

-- Greg

Wish they would have used RPC over Http/Https. But I guess it's probably a design flaw that probably dates back to the old days of computing and client server programming. It was probably sufficient back then when the majority of applications where intranet apps. Now that everything is web based and everything is on the extranet, the remote debugging functionality probably needs a redesign.

Any of the Visual Studio architects from Microsoft listening to this? :-)

Bummer man!

I_Love_DotNet