Freigeben über

What are your remote debugging scenarios?

  • Artikel

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

  • Anonymous
    June 22, 2004
    The comment has been removed
  • Anonymous
    June 23, 2004
    Firewall? Rarely (but not never).
    Without logging in? Yes.
    New credentials? Yes, often.
    Rather run a setup? No, not if it's avoidable.
  • Anonymous
    June 23, 2004
    What about cross plattform debugging?

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

    Is that possible with 2005?

    /Staffan
  • Anonymous
    June 24, 2004
    Yes.
  • Anonymous
    July 08, 2004
    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?
  • Anonymous
    July 08, 2004
    The comment has been removed
  • Anonymous
    July 12, 2004
    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,
    Mark.
  • Anonymous
    July 16, 2004
    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.
  • Anonymous
    October 19, 2008
    生产环境的调试不同于开发环境的调试，生产环境一般受条件限制，无论是在线调试还是抓dump，都不是很方便。比如生产环境的一个windows服务,你想用vs.net进行远程调试；比如你想让某个性能计数器达到一个值后自动抓dump；比如你想让某进程崩溃的时候自动抓dump，比如你想在程序里动态的生产进程的minindump；比如你想在iis应用程序池回收的时候自动抓取Dump。