I have vague memories of the floating point bug and will look at getting that in place as suggested.
Just to clarify here, all users are accessing the EXE using RDP. There is no "local" C drive as far as they are concerned. And while there is a drive mapped to a share, it is all self-contained on the same VM. So it seems odd that it might drop the network connection to itself but...
--
rk -----Original Message----- From: ProfoxTech [mailto:profoxtech-bounces@leafe.com] On Behalf Of Wollenhaupt, Christof Sent: Wednesday, April 12, 2017 5:59 AM To: profoxtech@leafe.com Subject: Re: VFP EXE and RDS random crashes
To that point--would copying the FRX/FRT locally and running from there be a better option to avoid that?
It would depend on which file is causing the problem... It certainly would be worth a try. If the EXE or any of the REPORT*.APP files is on the network it also would help to copy those to a local drive. Same is true for any DLL or OCX you use.
Another issue that causes crashes mostly when printing, but usually wouldn't result in a C6 exception, is the floating point problem. 15 years ago HP printers where notoriously famous for changing the exception handling for the floating point unit so that a division by zero caused a crash instead of returning NaN (not a number).
To work around this, we have
DECLARE _fpreset in MSVCR71.DLL _fpreset()
everywhere in our program where we access a printer driver. So before and after printing a report, selecting a printer, listing printers, etc.