Sometimes you need to to debug something that is simply doesn’t work as it should. It doesn’t throw an error so it’s a bit trickers to debug it with WinDbg or MDbg. In addition to that, you simply cannot (or should not) install a full blown Visual Studio installation on that machine.

For these scenarios exactly, Visual Studio’s remote debugging abilities exist.

At work, a friend had to debug such a problem. It didn’t throw an error and it worked on his machine (it always works on the developer’s machine 😉 ) but didn’t work on one of our test servers.

In order for the remote debugger of Visual Studio to work, one must install the Remote Debugger package that comes on the Visual Studio DVD on the remote computer. It’s a relatively small footprint installations.

NOTE: Be sure NOT to install this on a production server since the remote debugger needs to somehow talk to your debugger and it uses the network for that. Installing this (or at least keeping it enabled) on a production server might put the server at risk of being hacked!

Installing is the easy part. Now comes the configuration part since the debugging service authenticates both ways (both the machine running Visual Studio needs to authenticates on the remote machine, and the remote machine needs to authenticate on the machine running Visual Studio)

I’ve found two interesting article that can help you do that. One is a Knowledge Base article from Microsoft, the other a blog post for figuring out how to configure things when you are running in a domain-less (or domain different) envrionment:

  1. How to implement remote debugging in Visual Studio 2005
  2. Remote Debugging without domain accounts – from greggm’s blog.

If you follow these two articles you’ll get it up and running in no time.

If all else fails, printf debugging will probably still work (I’m referring to the broader definition of printf debugging which includes logging to a file/event log/whatever and not actually using printf’s to log stuff).