My team lives and dies by uses the Symbol Server and Source Server features in Visual Studio 2005 to help us with remote debugging and crash dump analysis of our numbered release builds. Together these two features let us open a dump or a debug session and have VS2k5 automatically find and download the symbols for our product DLLs from our symbol server, then go to our SVN repository and pull down the source files that went into those symbols.

I’ve recently written about the virtues and vices of remote debugging. Today I noticed another vice: the remote debug monitor doesn’t seem to honor the working directory specified in the debug settings.

The application I’m debugging fails noisily if it’s not run with the right working directory. Despite specifying a working directory in the debug settings, the resulting process’s working directory is still wrong. If I run the command without the debugger, using only a shortcut with an explicit working directory, all is well.

In my new job I do alot of work with low-level device drivers that can badly shitcan one’s machine if something goes wrong (as it so often does). Thus, it was something of a no-brainer to run my development binaries within a VMWare virtual machine.

However, this does lead to some unfortunate complexity. One of the most significant of these is the need to use the debugger on my host machine, to debug code on the virtual machine.

Since Visual C++ 6.0 at least, I’ve known of the Remote Debug Monitor, which is a lightweight executable shipped with Visual C++ that you run on a target machine to enable you to debug processes thereon, from a remote host across the network. It’s gone through various stages of shittiness, and now operates primarily via DCOM (presumably, using sockets was too reliable and straightforward).