Remote debugging tips

· by Steve · Read in about 3 min · (604 Words)

I used to use remote debugging as my primary form of debugging many years ago (we’re talking the early to mid 1990’s now), simply because it was impossible to debug code that was tinkering directly with the VGA registers to do things like Mode X any other way. These days I still find it useful although less frequently - I’ve used it to diagnose full-screen issues that couldn’t easily be tracked via simple log output, and at times I’ve used it to debug server applications (J2EE, via Eclipse that time) where the behaviour could not be replicated anywhere but a super-duper beast of a machine. However, I hadn’t set it up in VS2005 yet.

I have plans to set up a couple of extra machines in the office here in the near future to handle compatibility testing, one AGP machine and one PCIE (and one of them with an embedded GMA chipset hopefully), and I already have my wife’s machine for ATI testing, so it was likely I was going to need it again sometime. It came to a head in that I did some work on sRGB support for OGRE recently as part of a contract project I’m involved with, which worked on my 8800 but is borked on ATI machines in GL for reasons unknown right now. It’s a pain to go backwards and forwards with new binaries using simple logging to diagnose so I decided to get remote debugging set up again.

The basic instructions can be found on the MSDN site. It’s pretty much the same as my experience with older versions, except they’re a bit tighter on security now (but I’m on a small  LAN so I turned all that off and ignored the warnings). However there’s one sticking point - the Visual Studio 2005 Debug CRT. The remote machine won’t have the debug runtime unless it has VC installed (unlikely) so you can’t run full debug builds remotely without getting the debug runtimes installed, or changing the way you build your binaries which is undesirable. The debug runtimes are now (of course) using the side-by-side assembly setup, so you can’t just drop the msvcr80d.dll et al in the local folder, you have to install them (unless you do it as a private assembly which is not ‘officially’ recommended and again requires build changes). Whilst it’s easy to install the release CRT using the redist package, the debug runtime has no redist package because, well, you’re not allowed to redistribute it. Internally for testing it’s allowed but there’s no prebuilt package to help you get it set up.

You can supposedly do it manually from the merge modules by running this on the remote machine:

msiexec /i Microsoft_VC80_DebugCRT_x86.msm

Where the .msm is obtained from your c:\Program Files\Common Files\Merge Modules folder. However, I tried that and it didn’t seem to work - it appeared to set up the appropriate folders in the WinSxS area, but looking at it, it did not appear to follow the redirections to the newer DLL versions set up by VC SP1, probably because the .msm didn’t change with SP1 but the external profiles did. That approach just left me in familiar ‘The application failed to initialise’ territory.

So instead, I built a simple Setup and Deployment Project on my dev machine, added the Debug CRT from Project > Add > Merge Modules, built it and ran the resulting setup program on the remote machine. Hey presto, I can now hit F5 and see OGRE fire up on my wife’s machine across the room, pause, debug and resume it all without moving from my chair. Splendid.