Jeff's Blog

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.
Published Friday, August 24, 2007 4:05 PM by jeff

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

ronald said:

I am also trying to set breakpoints to debug an Exchange 2007 transport agent.  This is on the server itself, which should be simpler, but I cant ever seem to get a breakpoint to be reached.  If I attach to the MSExchangeTransport.exe process, Visual Studio says my breakpoints will never be reached.  The closest I have gotten is to attach to the dllhost.exe process, after which Visual Studio says my breakpoints will be reached, but when I send test emails through the server the breakpoint never activates, even though the custom transport agent is indeed working.

Do you have any hints as to how to get breakpoints to work with a custom Exchange 2007 transport agent?

September 19, 2007 6:20 PM
 

jeff said:

A couple of things to check:

For a transport agent, you want to attach to the MSExhangeTransport.exe process. If Visual Studio is telling you that it will never hit the breakpoints, the debugging system cannot find the sybmols file. First, be sure you're using the debug version of the dll. Second, add the path to the symbols file in Visual Studio. Third, make sure to use the "Default" method and not Native or No Authentication, otherwise you Visual Studio will not hit the breakpoints. Lastly, you might try coping the sybmols file (.pdb) to the same directory as your transport agent on the target system.

October 1, 2007 2:08 PM
 

Dimitri said:

Hello Jeff,

I am trying to debug a transport agent with no luck; still getting “no symbols have been loaded for this document”. You mention to make sure that the debug version of the dll is used.  Under “Project Properties -> Compile -> Advanced Compile Options” I have “Generate debug info” to Full. Is this enough? I can’t find any other place to define a dll as a debug version. I am using VS2008, .NET 3.5 and working on the Exchange 2007 Hub.

Thank you

September 22, 2008 4:12 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit
Powered by Community Server 2.1