What are your remote debugging scenarios?

I am constantly using remote debugging. I have one ‘development’ machine. On this machine, I have Visual Studio 2005 and an environment setup to build whatever version of VS I want. Then I have a bunch of test machines which run debug versions of Visual Studio. When I develop new code, I build it on my dev box, and deploy it to a test box. I also frequently remote debug to machines in the lab, or a machine in a testers’ office.
My setup is really simple:

  1. TS into the target machine

  2. On target machine: Start->Run ‘\\<dev_machine>\msvsmon\x86\msvsmon.exe’

  3. On dev machine: Start Visual Studio, and point at the target machine

In 2005, we have really optimized this scenario. You can now both native and managed debug without installing anything on the target machine. All you need to do is run ‘msvsmon.exe’ off a share. To make this easier, VS setup installs msvsmon into a folder that is tailor made to share out (C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger).

My question: How well does this fit the scenarios that you would like to do remote debugging?

  • Do you often need to debug across a firewall?

  • Do you often need to debug without logging into the target machine?

  • Do you often need to supply a new set of credentials when debugging?

  • Would you rather run a setup on the remote machine?

Comments (9)

  1. Firewall: no

    Without logging in: rarely

    New credentials: no

    Setup: definitely not. Usually the remote machine is a test box that we’re trying to keep completely unsullied. It’s better to run a single app, so we know that the setup didn’t install any extras/prerequisites that suddenly make our app work — thus causing a heisenbug.

  2. Firewall? Rarely (but not never).

    Without logging in? Yes.

    New credentials? Yes, often.

    Rather run a setup? No, not if it’s avoidable.

  3. Staffan Gustafsson says:

    What about cross plattform debugging?

    Compiling for IA64 (on x86 dev machine) and debugging on an IA64…

    Is that possible with 2005?


  4. Gregg Miskelly says:


  5. IgorF says:

    Firewall: no

    Without logging in: no

    New credentials: sometimes

    Setup: absolutely not!

    Now, what would be really nice 🙂 is if I could remote debug (both native and managed) from VS.NET2003 on my main dev machine to the Whidbey beta I have installed on a virtual PC running a different OS. Is there any way to make this work without installing/running the 2003 remote pieces?

  6. Gregg Miskelly says:

    No, we have made many big changes between VS 2003 and VS 2005. That said, you could go the other way quite easily. You could use 2005 as your main debugger and debug the code that 2003 is producing without installing the remote debugging components from 2005 – just run them from a share.

  7. Mark Nicolini says:

    Being able to debug VS2005 managed code using MSVSMON (like native) would be helpful. But are there any thoughts to having the ability to share out an installation of VS2005 for remote debugging only, like what could easily be done with a VS6 installations, without having to use MSVCMONMSVSMON? Losing the ability to run off of a share installation of VS when upgrading from VS6 to VS7 was a big impact on remote debugging.

    If MSVSMON is going to continue to be the only way to remotely debug with VS, then are there any debug performance enhancements to MSVSMON, especially the network communication layer?

    firewall? Sometimes with clients Internet Connection Firewall enabled.

    without logging into? No.

    new set of credentials? Yes.

    setup on the remote machine? No.

    A "Connect As.." credential dialog would be helpful when different credentials are needed to debug a remote system.

    It would also be helpful if all of the necessary debug DLLs be available in the tailor-made remote debugging share either by xcopy of via a environment variable setting (ie. MFC042UD.DLL, etc).

    It would also be helpful to define how MSVSMON can be used without disabling Internet Connection Firewall.

    When debugging native with no auth, it would also be helpful to publish the default ports that are used for MSVSMON so Internet Connection Firewall can still be enabled and the ports can be manually entered. Andor have an easy way to specify what port the client debugger should connect to when using /port.

    Thanks for the discuss opportunity,


  8. Gregg Miskelly says:

    Share out the whole installation: I agree with you that that was a nice feature that we lost when we moved to devenv.exe (instead of msdev.exe). However, currently, that is impossible. VC6 got away with that because it wasn’t a COM application. On the other hand, the debugger, and pretty much everything else in VS requires registration to work. We did a lot of work to make regular debugging work remotely without registration, but we are still far a way from a registration-less world. Maybe when we move to all managed code we will do that.

    Performance improvements: I hope so.

    Connect As: We would like to do this, but we have to scrap our current architecture first.

    Share out debug libraries: All of the VC shared libraries now require fusion, so they need to be installed (as opposed to xcopy installation). If you want to run your product without needing to install the debug CRT, I strongly recommend using the static CRT.

    Ports: We actually use multiple ports in /noauth mode. However, starting with XPSP2, the Windows Firewall allows you to open up ports by the name of the exe instead of by port number.

  9. 蛙蛙池塘 says:


Skip to main content