Remote Debugging in VS 2005

What do you do when you cannot reproduce an issue that is occuring in production in your development environment? Enter the nightmare that is Remote Debugging. For the better part of a day, I have been trying to remotely debug my Exchange transport agent on a production system. Unfortunately, I cannot reproduce the error in our development environment and I cannot install VS 2005 on the Exchange server, so I am forced to pull apart the DLL in production to see exactly what is going on. Well, to my surprise, Microsoft apparently wanted to make this as difficult as possible to accomplish. After scouring the Internet, I seem to have found a solution. Some notes that may save you some time:

  • To enable Remote Debugging, you need to run the MSVCMON.EXE file for your platform located under Program Files\Microsoft Visual Studio 8\Common 7\IDE\Remote Debugger (if you are on an x64 machine, the x86 version will be under Program Files (x86) and the x64 version under Program Files).
  • Be sure that the version of MSVCMON.EXE matches the version of VS 2005 on the debugging system.
  • The system running VS 2005 will need to know the path to the symbols file on the remote system. It is best to copy the symbols file to the same location as your DLL and set the path under Tools > Options > Debugging (tick Show all settings) > Symbols. Click the folder icon and enter the UNC path to the appropriate location. It is also best to browse to that folder via My Computer to ensure the debugging system can connect to the UNC share properly.
  • If your system running VS 2005 is behind a NAT firewall, forget about using Remote Debugging. All the testing I have performed and all the information I have found simply says this will not work. Furthermore, you will run into all kinds of problems if there is a firewall between the systems. It is best to use a system on the same subnet as the remote system.
  • Debugging managed code will not work using┬áthe “Remote (Native only with no authentication)” transport or “No Authentication” mode (as indicated by the “native only”) meaning you will have to enable authentication (use “Default” transport). Note that you can view the output of debug messages using the No Authenticate mode, but you will not be able to step through code or set breakpoints.
  • If the systems are not in the same domain or in domains that do not have trusts configured in both directions, you will need to create local users on each system so neither box can be a domain controller. The local users will need to have the same username and password.

Leave a Reply

Your email address will not be published. Required fields are marked *