>>Have you checked with the debugger what lines prompt the error ?

>No, I haven't. The problem only happens on one computer at the client site. The other 3 pc's show no such problem, and all the machines are supposedly configured alike. Their IT department doesn't like other people messing with their machines, and they are looking to see what might be different about this one pc, but I haven't heard anything from them yet.

As long as these machines have either unblocked USB ports or CD-ROMS you can start vfp's IDE and debug away as long as debug info is in the code - You don't need to "mess" with the machines. For a first try "nonintrusive" checking is much better IMHO - and other helpful tools from systernals for instance work from CD as well. It starts to get problematic if you have to replace installed exe/apps with debug ones: here I show pre-prepared batch files for saving and restoring the current state.

One other trick is to hide a switch for the coverage profiler via file() or some other backdoor loophole and set it on to get a log of the last steps leading to the problematic area - but working in the debugger is MUCH faster for me <g>. But that helped me when I had only remote access to locked-down customers machines via ISDN and could not work with my swiss army knife of debugging helpers.

regards

thomas