This week I was debugging a problem with a WPF application. Actually, it being a WPF app had little to do with the problem. No, what I was testing was the installer process.
We’re writing a new WPF frontend for an existing system and the application needs to installed via a InstallShield installer. It’s a legacy system and has dependencies on older systems and software. For example, during the setup we install a Access 2003 mdb file into the %appdata% folder. The installer is also supposed to install the prerequisite technologies, like .NET 4.0 and copy a files to numerous locations on the local drive. Then on application start we need to dynamically find these files. Trouble was, when the app started for the first time, it immediately crashed.
Looking through event log revealed a unhandled exception as the cause of the crash. The app has an event logger, but the code didn’t seem to be running. Checking the installer logs didn’t show any obvious problems either. I decided it was time to turn to Visual Studio remote debugging for help.
As you might have surmised by now, I’m testing the install on a virtual PC. It’s configured with undo disks, so I can roll back the install after each try. After thinking about it for a few minutes I decided put a breakpoint in the apps Main method. This is trivial in most circumstances, but I wasn’t sure how to accomplish this in my scenario. I didn’t want to install VS or other debuggers on the VPC. This seems like a prime use case for Visual Studio 2010 remote debugging.
I won’t bore you with the steps to configure you machines to enable Remote Debugging. After about 15 minutes work I had the remote debugging working. John Robbins has a nice post about setting up Remote Debugging  on a local Virtual PC if you want to create a similar setup.
Normally the way you remote debug it to start the msvsmon.exe on the VPC (be sure and run as administrator), then launch the app. Once the app is running, you return to Visual Studio and choose Debug\Attach to Process, then pick your instance of msvsmon and choose the remote process.
But thing are a little tricky here. Do you see the problem with that approach? Yes, by the time you get the app running and return to Visual Studio your program is long past executing the code in the Main method and other startup methods.
My solution, put a 30 second Thread.Sleep in the Main method. That gave me time to switch back to the other screen and get the debugger attached.
App app = new App(); Thread.Sleep(1000 * 30);
.. breakpoint here app.MainWindow = new MainWindow(); app.MainWindow.Show();
It worked perfectly, I was able to trace the problem to a typo in the installer. I’m sure there are approaches to take however. Do you have a favorite technique?On Aug 9 2010 9:05 PMBy writscher