I'm trying to set up remote debugging across domains. My Windows 7 workstation running Visual Studio 2010 is on one domain and I'm trying to debug an ASP.NET app running in IIS 7 on a Widows 2003 server box in another domain. I have found many instructions on how to set this up, this being the best, most clearly written one: http://blogs.interknowlogy.com/2011/11/16/remote-debugging-from-visual-studio-2010/
However, I can only seem to connect to the remote debugging monitor on the server if Visual Studio is being run as the local user on my workstation, not as the domain user. This creates a number of challenges, such as loss of source control connectivity. When I try to connect using the domain user I get the following error: "Unable to connect to the Microsoft Visaul Studio Remote Debugging Monitor named 'username#servername'. The specified account does not exist." (I have substituted a generic username#servername for the actual values)
I have found a number of sources suggesting this will work with the domain user running VS2010 but have had no luck. Any idea what I might be missing?
Solved
First, i've read #KyleMit's answer on the same question and done all steps.
But, for across domain debugging also need to edit C:\Windows\System32\drivers\etc\hosts file on local computer.
Just add remote computer's ip address like this:
172.172.172.172 SRV-TEST-ADRESS
Where:
172.172.172.172 - ip address of your remote server
SRV-TEST-ADRESS - Server's name from Visual Studio Remote Debugger
Monitor on remote computer
You can know your server's ip address by ipconfig in cmd
After that, i could attach to proccess on remote computer across domain.
Related
In Visual Studio 2015 RC, When trying to remote connect to another machine for remote diagnostics ( or to deploy an app to a Raspberry Pi ), Whilst searching for Remote connections it fails and returns with "Found 0 Connections on my subnet" even though there are 2 devices currently visible to the IoT Core Watcher.
If we ignore this and set the IP of the machine and build -> Deploy, It will fail and bring an error up of
Error : DEP2100 : Cannot copy the file "FILENAME" to the target machine "IP / Name".
Attached is a screenshot of our problems.
Visual Studio Failing to find devices and IoT Core found 2
Reason for the error: Ethernet was connected to Router not Host PC.
Connecting to Host PC and enabling network sharing works.
The search is not currently working.
Deploying an application by manually providing the IP address is working though. I reviewed the screen shot that you attached. I don't understand why you have entered an address of 169.168.137.79 when the device is at 192.168.137.79. Is this a typo? Everything else looks ok.
Mark Radbourne (MSFT)
I have a c++ program running on a remote machine.
I'd like to debug it from my machine.
I've installed remote debugging services (msvsmon.exe ) on the server.
Firewalls are not active not in the client nor in the server.
The program is running on the server (.pdb file is also there).
In the client I open the project in VS2010 , I go to debug->attach to process.
In the qualifier field I copy the value of the server name in msvsmon.exe.
When I hit enter, I get an error prompt saying :
"Unable to connect to Microsoft Visual Studio Remote Debugging Monitor named Administrator#TESTER1, the requested name is valid, but no data of the requested type was found"
In the server, the Authentication mode in msvsmon.exe is set to Windows Authentication.
Any help will be much appreciated.
Regards,
Omer.
Take a look at:
How to: Set Up Remote Debugging from Microsoft
Remote debugging with Visual Studio 2010 from CodeProject
In your case, take note of the suggestions regarding native debugging and windows authentication.
In my experiences with remote debugging a machine that is on my local network, I bypass windows authentication and setup the remote msvsmon.exe to allow anyone to connect to port 4015. So, then in the 'Attach to Process' dialog I select Transport > Remote (Native only with no authentication) and for the Qualifier I enter TESTER1:4015 or TheIPAddress:4015 if the name of the PC cannot be resolved.
I am trying to set up remote debugging from my development machine into a production environment running in a virtual machine, but no matter what I do I get the following error:
Unable to connect to the Microsoft
Visual Studio Remote Debugging Monitor
named . The
Visual Studio Remote Debugger on the
target computer cannot connect back to
this computer. Authentication failed.
Please see Help for assistance.
This is my setup:
Host Machine:
Windows 7 Professional x86
Visual Studio 2010 Ultimate
Virtual Machine:
Windows 7 Professional x86
Both computers are on the same domain, with the same username and password. The firewall on the remote computer is turned off and the firewall on the host is on, but turning it off produces the same error. The accounts on both machines are members of the Administrators group and running both msvsmon and visual studio as administrator or either/or produces the same result. When I put the server name in the qualifier field in "attach to process" and click refresh, I can see the log on the remote machine saying that the host is connected but that is followed immediately by the above error. Lastly, and this may be the most important piece of information, when the authentication fails, I get an entry in the even log that states that a user account was locked out:
A user account was locked out.
Subject:
Security ID: SYSTEM
Account Name: MyHostComputerName$
Account Domain:
DomainWhichBothMachinesAreOn
Logon ID: 0x3e7
Account that was locked out:
Security ID:
MyHostComputerName \ MyUsername
*(which is identical on both machines)* Account Name:
MyUserName
Additional Information:
Caller
Computer Name: MyVirtualMachineName
I have read seemingly every tutorial, help ticket and random bit of information regarding this problem and remote debugging in general and tried just about every "quick fix". I would be very appreciative of any ideas. I can provide any additional information if needed. Thanks in advance.
"MyHostComputerName \ MyUsername" seems to indicate the VM service is trying to authenticate with a local user, not the domain user
have you created the same user & password as local accounts on both systems?
http://msdn.microsoft.com/en-us/library/ms164725.aspx
I had this same problem running VS 2010 Pro on Windows 7 Pro accessing Remote Debugger 2010 on Windows 2008 R2. I had created identical accounts on the server running the debugger and on my domain. I was running under my identical accounts both visual studio and remote debugger with administrator rights and with the firewall turned off. on both systems.
the error I got was "... the visual studio remote debugger on the target computer cannot connect back to this computer ..." I found this issue with both VS 2010 and VS 2005 so I knew it was an issue with my system
SOLUTION - add a local user account to your system running visual studio as a domain account won't work (you can run visual studio under the domain account, you just need the local account to be present with admin rights assigned).
I know this answer is for an old thread but there are a number of threads out there on this issue with no solution.
Go to target computer (that you want to debug remotely), open windows explorer and visit computer from which you are debugging. It will prompt for username password. Enter credentials for account that exist on both computers and has relevant permission. After it authenticates you will be able to use remote debugger.
My config was BOTH COMPUTERS IN WORKGROUP.
In my case when adding mu local computers credentials to remote host problem solved.
The credential is the workaround for the case when you have a "domain admin computer with vs studio" machine trying to remote debug a "non domain admin computer" machine from different domains.
I need to do remote debugging of managed code (.NET) on a server hosted on a different network. Neither the client or server is on a domain so i have to use the public ip of the server.
I'm trying to use Visual Studio -> Attach to process -> default transport with the qualifier john#xx.xx.xx.xx but it's not working.
I get the error message : "Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'john#xx.xx.xx.xx'. There is no server by the specified name running on the remote computer"
This error message tells me i can connect just fine but it can't find the msvsmon instance (which is 'john#WEB-001'). So i tried to use the combination of qualifiers such as WEB-001\john#xx.xx.xx.xx and xx.xx.xx.xx\john#WEB-001 but neither are working.
If I choose the transport "Remote (Native only with no authentication)" it connects just fine and I can see the process list on the server but it is pretty much useless because I can't debug managed code.
The administrator 'john' exists on both computer with the same password
Windows 2008 R2 X64 (Server)
Remote debugging component (VS2010) X64 installed
Firewall off
Msvsmon new server named 'john#WEB-001' running as john
Windows 7 X64 (Client)
Visual studio 2010 running as john
Firewall off
Any idea how to fix this, or is this scenario not supported? Thanks
having you tried putting web-001 in your hosts file, and connecting as john#web-001?
Try adding the server name to your hosts file:
192.168.1.100 WEB-001
Replace the IP with your own. Native code debugging is done over plain TCP/IP with no security but native code requires DCOM to enforce security, I don't understand the reason but ....
I know this is an old thread now but.
When the remote debugger is first installed you can set a firewall setting that allows all web traffic or only subnet connections. Run the configuration again to allow all web traffic.
Also, as the Administrator account, not a user in the Administrator group, Shift+r-click on the debugger shortcut to execute as a different user. Enter in the other user account that has the same username and password as the machine you are debugging with, in this case john.
This is the process I have to use.
I'm debugging a vb.net windows program which I've upgraded to a VS 2010 solution, targeting Framework 2. I need to step into a webservice's code. The web service is framework 3.5, also vb.net, running on a windows 2003 server on our LAN. I've seen a ton of crap on the Net about it, mostly other people who couldn't get it working either.
The error I get in VS2010 is the exact same one I got before upgrading the project from VS 2005:
Unable to automatically step into the server. Connecting to the server
machine [servername] failed. The Microsoft Visual Studio
Remote Debugging Monitor (MSVSMON.EXE) does not appear to be
running on the remote computer. Please see Help for assistance.
So I did what Help said to do and ran the VS 2008 remote debugging wizard on the host server. I have verified that the remote debugger is running as a service on that machine. And it still fails.
Little help? THANKS
Just in case anyone comes here looking for this answer, here it is. No goofy 'Attach to Process', no weird bad instructions
from websites going off on a million stupid tangents. This answer has been FALKENIZED.
When on the same LAN and on the same domain, remote debugging from Visual Studio 2010 works when you do the following steps.
on web service host machine, share the web application folder where the web service lives; give yourself 755 permissions.
oops, give yourself wrxr permissions.
on local development machine, map a network drive to the [web service host machine][web app] folder you just shared.
copy the Visual Studio 2010 remote debugger folder (containing msvsmon.exe + support files) to web service host machine.
Make sure you get the correct platform for your host server, e.g. x86, x64, etc. Remote debugger is found here:
C:\Program Files\Visual Studio 2010\Common7\IDE\Remote Debugger[platform]
on web service host machine, drag a shortcut from the newly-copied debugger to the desktop, then start the remote debugger
on local development machine, step thru code. when reaching a call to the web service, you'll be prompted to navigate
to the location of requested web service code file, which will then be available in your mapped path. Do it.
Finally after 1000000 headaches, you may start debugging your web service. CONGRATULATIONS