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?
Protect your business with industry best practices.
Atmosera’s business is built on ensuring customer environments are secure from design through deployment and to provide solutions which are realistically implementable. We provide managed Information Security (InfoSec) and compliance options across the entire computing stack, from connectivity to applications, with stringent physical and logical security controls. We take on the security and infrastructure concerns by becoming an extension to our customer’s team or their application development vendor. In that partnership, Atmosera shares the responsibility and liability associated with maintaining a secure environment, and stands by that commitment with a guarantee based on the defined lines of responsibility.
All Atmosera customers benefit from more than technology by also getting processes, policies, training and 24x7x365 technical resources. Customers have the peace of mind of knowing an industry expert has performed a thorough risk assessment, identified a remediation plan and provided ongoing audit support to ensure customers stay secure. Best of all, Atmosera understands this level of service is — and will continue to be — required year after year.
Define your objectives.
We partner with your team to define the right security profile for your business needs.
Build your foundation.
Together we develop comprehensive best practices encompassing all aspects of security: people, process and technology.
Execute your roadmap.
We collaborate to build and evolve an information security program that bolsters your security profile.
Atmosera comprehensive services.
InfoSec is an umbrella for a multitude of services aimed at helping secure your business and deliver the peace of mind which comes from knowing your business is properly protected. Our services are tailored to meet each customer’s specific needs including basic and enhanced versions of the following capabilities:
- Managed monitoring services both passive and active
- Operating System (OS) management
- Managed data backup and protection services
- Managed shared and dedicated firewalls and Virtual Private Networks (VPNs)
- Managed log services including File Integrity Management (FIM) and Security Information and Event Management (SIEM)
- Managed identity services and vulnerability scans (V-Scan)
Industry best practices.
We follow a number of industry best practices when shaping the security profile for a customer. This includes leveraging team members with certification in both Certified Information Systems Security Professional (CISSP) and Information Technology Infrastructure Library (ITIL). We have trained professionals with advanced certifications in a number of specialities. We aim to protect each customer with a Defense in Depth approach for information assurance in which multiple layers of security controls or defenses are placed throughout an IT system to harden the outside of network, consider implications end-to-end, and protect against attacks from the inside which is the number one source of breaches.
Risk-free consult
We offer customers the opportunity to explore their security profile and help identify how we might help.