Remote debugging in Visual Studio works great if both machines are on the same domain and/or workgroup. It also works dreamily if you’re doing straight native C++ where you can use the TCP/IP as the debugging transport. The problem comes in when you need to do remote debugging for managed code across domains or workgroups. It doesn’t work because .NET remote debugging relies on DCOM, which as a transport protocol does not jump workgroup or domain boundaries.

When I have to remote debug across domain/workgroup boundaries, here’s what works for me. It’s not an ideal solution but until Microsoft allows us to debug .NET code with pure TCP/IP this will get you at least started. Again, your mileage may vary and your network admins may not let you perform the following so you’re on your own with these steps. Finally, I’m assuming you know how to set up remote debugging for the supported same domain/workgroup scenarios. If you don’t you should read the documentation to understand what I’m talking about here.

The issue with DCOM is there’s a security ramification where an account one domain does not have rights on the other workgroup or domain. The big trick is to do your remote debugging with local machine accounts. DCOM first attempts to make the connection with machineusername account and if that does not work, it falls back to the username using the hashed password. As long as the username and password on the both machines is the same, DCOM can make the connection.

On the machine where Visual Studio runs, called the local machine, open up an elevated command shell or PowerShell window with administrator rights and execute the following command. Yes, you can do the same through the GUI but this is much faster. Don’t fear the command line!

net user username
password /add


That creates the user account you’re going to use for Visual Studio.

On the machine where your application runs, called the remote machine, open up an elevated command shell or PowerShell window with administrator rights and execute the following commands. Obviously you’ll be using the same user name and password you entered on the local machine.

net user username
password /add

net localgroup administrators remotecomputernameusername /add


With the same computer accounts on both machines account life is easy. On the remote machine, you’ll need to login with the new account or if you’re logging in with a different account, use RUNAS.EXE to fire up MSVSMON.EXE like the following.

runas /user:remotecomputernameusername<full path>msvsmon.exe”


With the remote debugging stub waiting for connections, you’ll need to start Visual Studio on the local machine with the account as well.

runas /user:localcomputernameusername<full path>devenv.exe”


With both sides running with the same account and password, you’ll work around the DCOM bumps and get your remote debugging across domains and/or workgroups functioning. As I mentioned, this approach isn’t ideal because you’re now running Visual Studio in a different account so all your settings, extensions, and drive mappings aren’t there. The good news is that those are pretty simple to set up especially since you can export and import your Visual Studio settings.

One problem you’ll run into with this approach is when you need to attach to a process running with administrator rights.

The issue is that MSVSMON.EXE itself is not running with administrator rights. One option is to log into the machine with the local username, right click on MSVSMON.EXE in Explorer and choose “Run as administrator.” Another option, which I do instead, is to use my Elevate program that starts processes as an administrator at the command line. When I need MSVSMON.EXE running with administrator rights, I simply do the following.

runas /user:remotecomputernameusername<full path>elevate <full path>msvsmon.exe”


Right now some of you are sitting there thinking that instead of creating the completely separate account to run everything in, why not just create a machine account on the remote machine that matches the name of the domain account you want to use? That seems to make sense, but you’ll have a small little problem. The DCOM connection only works one way and you’ll get an error.

While not a perfect solution, using machine accounts with the same usernames and passwords on both machines will at least let you do remote debugging. In some cases this may cause more trouble than it’s worth, but I thought it was worth mentioning the approach. One of these days full remote debugging with complete security will be built into the operating system. A boy can dream, right?

  • Thank you, thank you, thank you. I can’t recall how many times this has hit me sqaure in the nose. (BTW, you may want to mention the SysInternals ShellRunAs utility to add some extra flair to this solution…)

    Thank you for taking the time to post this. It will save lots of us lots of headaches out here…

  • links for 2010-06-17

  • I have set up a VSDEBUG user with password of DEBUG on my local and the remote server like you have said. All commands succeed and I can start the Remote Debug Monitor as the VSDEBUG user and Visual Studio locally as the VSDEBUG user, but when I try to Attach to Process I just get a message that:

    “Microsoft Visual Studio Remote Debugging Monitor does not appear to be running on the remote computer.”

    If I switch to Native Only things show up, but it did that even without the special user. Problem is I am trying to debug ASP.Net and it doesn’t work with Native Only. Any ideas?

  • This week I was debugging a problem with a WPF application.  Actually, it being a WPF app had little

  • I prefer to use PsExec from Sysinternals, most Administrators know the tool and don’t start shouting when I ask them to copy it to the production servers. PsExec doesn’t allow “-u” and “-h” at the same time, so I figured out another way:

    psexec -i -h c:temppsexec -i -u nordine “c:tempREMOTEDEBUGx64msvsmon.exe”

    Et voilà!

  • Nicely done and very helpful! Thanks.

  • wds_admin

    I succeded connecting in the single domain senario but when trying to debug using the cross domain senario I get the message “The debugger cannot connect to the remote computer”. The remote computer is connected through a router. Does this requires any additional settings? In case the internet ip address is 70.xx.xx.xx and my remote computer is 10.xx.xx.xx, how do I refer to my remote computer?Thanks in advance!

  • jrobbins


    I bet there’s some IPSEC issues going on with your cross domain. You’ll probably get it to work if you drop one of the machines to a workgroup.

    – John Robbins

  • wds_admin

    It’s not working for me 🙁 . I have my debugging computer on our company’s domain and the other on a workgroup. I created local accounts on both computers, started msvsmon and devenv on each, set the debugging properties in the project to “run on a remote machine”: “robot” (the name of the domain machine). (Do I need to specify “debugger@robot”?)

    The error message is: “The system cannot find the path specified.”

    The path to which it refers DOES exist on the debugging computer.

    This is terribly irksome. I feel like it’s trying to use the path to the program in the bindebug directory from the debugging computer and resolve it on the application-running computer, but that doesn’t make any sense. Anyway, let me know if you know how to fix it or if you’ve come across this before.

  • wds_admin

    Didn’t work for me either. VS 2010 on one machine/domain. Remote debugger on a separate machine/domain. Both Win7 x86. Created local admin accounts with same name and pwd and both machines. When trying to attach from VS 2010, Remote debugger shows connection but VS 2010 comes back with “Unable to connect to remote debugger” with check firewall message. Both firewalls are off? This doesn’t work. Don’t waste your time. MSDN says it should work? Typical MS.

  • wds_admin

    On my remote computer I tried
    net localgroup administrators remotecomputernameusername /add

    It says that
    there is no such global user or group: [myremotecomputer][myusername]

    My local computer is within a domain but the remote computer is not in the domain, it’s a stand alone.

  • wds_admin

    Thanks! Works great for me.

  • wds_admin

    Just want to say THANKS. This was a HUGE help, and I was not anywhere near figuring this out on my own.

  • Brilliant Blog !!
    Just used it to remote debug (using Visual Sudio 2012) our app running on a Windows 8 machine in our test domain … I was that close to installing VS2012 on the actual machine and doing everything local, until I came to your site …. Many Thanks !!

  • wds_admin

    Nicely written, but doesn’t work for me 🙁
    Local and remote are in different domains. I’ve created local admin accounts as mentioned. I’ve shut down both firewalls. Still getting “MSVSMON,exe does not seem to be running on the remote computer.”
    I’m using VS 2013 update 2 (and the exact corresponding Remote Debugging tools).

  • jrobbins


    With VS 2013 you don’t need to do this. Now that they use TCP/IP as the transport mechanism as long as the two machines can ping one another remote debugging will work.
    – John Robbins

  • Nice post. Is it possible to make the VS debugger start a user session on the remote machine? i need to de debug an application which does things during logon.

  • Nice post. Is it possible to make the VS debugger start a user session on the remote machine? i need to de debug an application which does things during logon.