I sometimes run a debug build without the CVI IDE - instead of the OS crashing the program you get a CVI popup giving you some idea of where the error occured and what the problem was.
Or, you can 'wrap" the CVI application in a C++ program that has an exception handler and catch any runtime exceptions coming up out of the CVI application. The app doesn't crash, but your chances of doing something meaningful aren't particularly good due to limited info about the runtime error. You can, however, figure out the nature of the error (e.g. was it a divide by zero error).
When running the production build I've noticed that with pointer errors on WinXP SP2 we seem to get errors from the anti-worm service in XP SP2 that looks for data being executed as code.
You could try remote debugging - run the debug build on the target and use the CVI IDE from another machine (i.e. your development machine). At least that way you don't have to install the development system on the target. I use a laptop to host the IDE, that way I can walk up to a target and hookup with a TCP/IP connection and debug.
There's just no real substitute in C / CVI for not doing stupid things in the first place (e.g. de-referencing null pointers or dividing by zero) unless you run the debug build to let CVI help you find the problem.
Menchar
