How can I track down this nasty bug?

[Paul McKenzie]

OK, thanks again Paul. I tried your crash program and it doesn't appear to do anything at all when run on the servers. It just opens the black dos window for a fraction of a second and then closes. There's no Dr. Watson, no "Sorry for the inconvenience ...", or anything else. That's weird because I've seen Dr. Watson run on the servers when other programs crash, and when I run your crash program on my local machine it causes the "Sorry for the inconvenience ..." dialog to come up. I guess crashing is much more complicated than I realized.

I suspected as such. On the machine where you see just the black OS window show up, I would assume the compiler is not installed on that system.

So your machine is basically "debugerless". Just to let you know, if you did have a crash dump set up, you would see that your crash dump routine would replace the window flash, and on your other machine, it would replace the "Sorry for the inconvenience" dialog. That's the beauty of the crash dump. It doesn't matter if the machine has Dr. Watson or not. If you did a google search on "minidumper" "crash dump", etc. you should come across some source code that allows you to intercept and run your own routine, including creating a crash dump file.

Is there any way to run my server program in debug mode on these remote machines even if they don't have MSVC installed?

Yes, it's called "remote debugging".

You need these things to invoke this:

1) A TCP/IP connection to the server machine from your build/develop machine (IP address is OK, as well as any valid web address to the server).

2) The server must run the MSVSMON.EXE program. This is the debugging agent between the server and your develop machine.

3) Your application, built with debugging info (you can build release versions with debugging info -- just go to the debug options for your project and turn on debugging).

Then all you do is install the app on the server, and then on your build machine, connect to the server machine in Visual Studio via the debugging project option. You go in the Debugging options for your project and set up remote debugging (IP address of the machine, how the program is run on the machine, whether you want to attach to a running process, etc.). The server machine need not have Visual Studio installed, or have access to your source code -- all of that stays on your build machine. To get your feet wet, you set a breakpoint in some function you know will get called, and voila, you'll see that breakpoint is hit if you've got everything set up right.

The above is too much for me to get into, as it is documented in your Visual C++ manual, but yes, this is how you debug apps on a remote machine from your develop machine. When you first get it working, you wonder how you could have gone on for so long without knowing about this. You're actually running the application on the machine that has the issue, and not simulating running it on your build machine or some other machine.

Regards,

Paul McKenzie