Required settings to connect to Visual Studio Remote Debugger (msvsmon) over the network

Question

We're trying to get remote debugging working across domains from a windows 7 machine to a windows xp home machine. The machines are VPN'd together using LogMeIn Hamachi.

I've checked over the MSDN guide on getting Remote Debugging set up thoroughly and have gotten past a lot of errors, but I'm constantly running into blocks. I can get it into native debug but can't get managed debug to authenticate. Here are the things I've already done --

• Visual studio and the debugging monitor are running on their respective machines as an identical administrator user -- debug/debug.

• the debugger initially refuses to run on the xp machine, so i'm running it thusly: runas /user:debug "c:\josh\msvsmon.exe -nosecuritywarn -noauth -anyuser" and then switching it over to managed mode from there.

• hamachi gives the computeres virtual IPs but not hostnames. I've resolved the IP of the remote computer to its host name in my local hosts file -- this got me past vstudio not being able to find debug@HOSTNAME and to my present place in paradise.

• edit: right, my current error. I try to log on and get a "Bad Logon and Password" error in authenticated mode. I tried manually setting that "guests resolve to local accounts" message and that did not help.

Feel free to ignore all of those specific bits and just address my general problem -- i only included them for thoroughness and backstory etc.

Answer 1

Sniffing shows that VS 2010 connects to the remote debugger through SMB. It opens IPC$ share then tries to open named pipe \Microsoft.VisualStudio.10.0.Remote\<name>, then \Microsoft.VisualStudio.10.0.Remote\svc=msvsmon100 (see Can named pipe names have backslashes? about the additional backslashes).

The <name> is customized with the /name arg at msvsmon's side and prepending <name>@ at VS side. By default, it's the user name msvsmon/VS runs as. I dunno when the 2nd pipe is created; in authenticated mode, it isn't.

So, you need the rights and settings to:

1. connect to the remote server via SMB (via NetBIOS or directly) and authenticate successfully;
2. connect to the correct pipe and use it.

---

• For the 1st item, the easiest thing to do is create an account on the remote machine with the same name and password as which VS is running as. This is what Remote Debugging Across Domains article recommends too.
  • Another possible way is to make saved credentials for the remote server. Note that the server name you save creds for must read precisely the same as what you connect to (it doesn't have to be a name, it can be an IP just as well).
• For the 2nd item, you need to specify the correct <name> at VS side and/or server side and have the desired access according to the pipe's ACL for the user you authenticated as. Apparently, the "Permissions" window in msvsmon reflects the ACL ("Debug" must correspond to the required set of ACL flags). In my test, msvsmon refused to add users to the permitted list with an obscure error. So, the easiest thing is still to create the local user and add it to local admins.

Answer 2

Joshua, what does the "across domains" detail mean? Are the Win7 and WinXP boxes members of different domains? Do the domains trust in both directions? Are the "debug" user accounts local or domain accounts? And is the XP box really an XP Home edition? If so, how is it even joining to a domain?

Are there any more details for the error that's currently being encountered - is there any additional text in the error dialog? Is there any scrap of additional detail in the Event Logs on the target box (e.g. are you seeing any Failures in the Security event log - are Failed Logon/Account Logon attempts being logged? Does VS or the app-being-debugged log any detail in the Application or System log)?

What kind of app are you remotely debugging on the XP machine? Is it ASP.NET or something else?

If Windows/Visual Studio are providing an accurate picture of the problem with the "bad logon and password" error, then it suggests that by the time the managed code tries to check whether the remote process has sufficient permissions to access the object/process being debugged, the token for the remote debugging process is no longer the "debug" user, and/or the token no longer includes the "Debug Programs" privilege.