Remote debugging between different domaine

[Yves Gagnon]

Hi,

I try to debug a WCF hosted in a windows services on a serveur that is on an
other domaine then my developpement machine. I tried many things without
succes. Here is what I tried:

First I installed on the server I want to debug, the remote debugger tools
from the VS 2005 CD. I just install the windows application. I tried from
there to debug, without succes. I could connect to the remote machine only
when the msvsmon.exe is in the mode 'No authentication (native only)'. But
the problem with that mode is only the native code is available to debug. In
my case, I want to debug .net code. When I tried to put the mode to "Windows
authentication" , I receive the following message "Unable to connect to 'name
of machine'. The microsoft Visual Studio Remote Debugging Monitor is either
not running ont the remote machine or is running in Windows authentication
mode." I confirme that the remote debugging monitor is running on the remote
machine. What is left is the mode, and it's a fact that it is in 'Windows
authentication' mode. But it exactely what I need if I want to debug .net
code.

I found an article that show an option to that situation. It recommend to
create a local user on both machine, with administrators rights and with
the same name/password. And to log on the remote machine with that new user
et start de windows debugger app with the 'run as administrator'. Do the
same on the client machine, and start VS2005 with 'run as administrator'. No
succes. Still have the error when I tried to attache to the process. In the
'attach to process' windows, I choose the option 'Remote' and put the name
of the computer like wdefacevo1. I could ping that computer, and like I said
before, if I change the mode on the remote computer, I could see all the
process of the remote machine.

If any one has an idea to solve that problem, it will be very appreciate.

Best Regards
Yves

[Jeffrey Tan[MSFT]]

Hi Yves ,

Remote debugging involves two-way communication between the Visual Studio
2005 debugger and the Remote Debugging Monitor (msvsmon.exe). Since these
two machines reside in different domains, there are no trust relationship
between the DC of these two domains. So the Windows security authentication
can not establish in your scenairo.

Yes, one way to resolve this problem is creating two local Administrator
accounts with the same username/password on both machines. The link below
is the official document for cross-domain debugging:
"Remote Debugging Across Domains"
http://msdn.microsoft.com/en-us/library/9y5b4b4f.aspx

After doing this, do you run both the VS debugger and msvsmon.exe under the
this same local Admin account? If so, what error do you get while
performing remote debugging? Is it still "Unable to connect to 'name
of machine'" error dialog? Also, in which step do you get the error?

Finally, what OS are your client&server machines?

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== ===========
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.

This posting is provided "AS IS" with no warranties, and confers no rights.

[Yves Gagnon]

Hi Jeffrey,

Thanks to take time for this issue. To answer your questions: Yes I run
both, the VS debugger and msvsmon.exe under the local admin account. The
error I received, is from VS debugger when I tried to connect from the
attach to process windows. I received this error:

"Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor
named 'the server'. 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."

One observation at this point. When I tried to connect to the remote server
from the attach to process windows, I used the following information: In the
"transport" info, I choose "Default", in the "Qualifier" section in put info
like gagnonyv@wdeuac ev01. gagnonyv is the local account that was created on
both computer, with the same password. When I press the enter key, if a take
a look on the remote server, I see an entry in the remote debugging monitor
saying "wdeuacev01\gag nonyv connected. That info told me that the connection
worked, but like the message say, the problem seam to be that the remote
computer is unable to do his job to return info to VS.

Both machine has OS windows serveur 2003.
I hope the preceding info is clear to explain the situation.

Best regard

Yves
""Jeffrey Tan[MSFT]"" <je***@online.m icrosoft.comwro te in message
news:Sx******** ******@TK2MSFTN GHUB02.phx.gbl. ..

Hi Yves ,

Remote debugging involves two-way communication between the Visual Studio
2005 debugger and the Remote Debugging Monitor (msvsmon.exe). Since these
two machines reside in different domains, there are no trust relationship
between the DC of these two domains. So the Windows security
authentication
can not establish in your scenairo.

Yes, one way to resolve this problem is creating two local Administrator
accounts with the same username/password on both machines. The link below
is the official document for cross-domain debugging:
"Remote Debugging Across Domains"
http://msdn.microsoft.com/en-us/library/9y5b4b4f.aspx

After doing this, do you run both the VS debugger and msvsmon.exe under
the
this same local Admin account? If so, what error do you get while
performing remote debugging? Is it still "Unable to connect to 'name
of machine'" error dialog? Also, in which step do you get the error?

Finally, what OS are your client&server machines?

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== ===========
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.

This posting is provided "AS IS" with no warranties, and confers no
rights.

[Jeffrey Tan[MSFT]]

Hi Yves,

Thank you for the detailed information, it is helpful for analysis.

The error message is documented here:
"Unable to Connect to the Microsoft Visual Studio Remote Debugging Monitor"
http://msdn.microsoft.com/en-us/library/0773txhx.aspx

As I examined, the most possible reason is "3. Verify that the remote
machine is accessible on the network."

Your further information should have confirmed that the VS2005 debugger
client has successfully connected to the remote debugging monitor. I agree
that the problem is that the remote machine can not send back the
connection reply back. As we know, the remote debugging requires mutual
ways authentication, see Gregg's blog below:
"Remote Debugging without domain accounts "
http://blogs.msdn.com/greggm/archive...04/237519.aspx

Since the Windows2003 has almost the same setting as Windows XP SP2, I
assume this is a firewall issue of your VS2005 debugger client. You may
have to open the firewall port on the client machine so that it can accept
the reply.

You may follow the instructions in the two articles below to open the
firewall ports; I assume this will resolve the problem:
"How to: Manually Configure the Windows XP Firewall for Remote Debugging"
http://msdn.microsoft.com/en-us/library/bb385683.aspx
"How to turn on remote debugging for Visual Studio 2005 in Windows XP with
Service Pack 2"
http://support.microsoft.com/?scid=k...8099&x=15&y=10

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
=============== =============== ===========
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
ms****@microsof t.com.

This posting is provided "AS IS" with no warranties, and confers no rights.