>Hi Al,
>
>>According to MSDN ( http://msdn.microsoft.com/en-us/library/13cfzh6x%28VS.80%29.aspx ), "Visual FoxPro includes the VFPClean.app tool so you can make sure all core Xbase and other files are set appropriately."
> I'm not familiar with this tool. Can you tell me what it will clean up exactly?

I don't know exactly what it does. I'm not sure source is available for it. I just know it has been provided since VFP7. I *suspect* it may register or re-register OLE servers/ActiveXs or files as needed, perhaps make sure registry entries are as expected.

>>if you're using antivirus, you might try temporarily disabling any real-time scanner and/or exclude VFP folders, file types and temp file folders from being scanned.
> I don't think this is the problem because the same FRX in the same .app file behaves properly in one application but not in another on the same machine.

Hmm, well at this point I can see two general things to look at:

1. What are the significant differences between the successful app and the one that blows up? How do each of them call the FRX, what are their environments when the FRX is called?

2. Is there any unusual software running on both your machines and the client machines?

Without a repro, it's hard to say if you're actually running into some VFP bug that manifests under unusual circumstances.

With some VFP crashes, a file gets created called (IIRC) vfperror.log. Do you have any file like that, and if so, what are its contents?

A crash in a report preview really sounds like a hardware driver issue. My understanding is VFP first uses the default printer driver to generate the report, which then gets rendered using the video driver. A problem with either could cause the crashes you're seeing. But, you say the problem happens on disparate hardware, which makes this theory unlikely.

SWAG territory - if you run the problem report with different data, or with less (say, half) the data, is there any difference? Hopefully you're not generating previews with hundreds or thousands of report pages (?)

As a last resort, on occasion I've re-created problem VFP files from scratch. With a FRX, you could either:

1. Create a fresh new FRX and copy/paste the items in the old one to the new. Relatively quick, but prone to copying corruption if there is any

2. Completely re-create the FRX from scratch, without copy/paste from the old

If you do this it might be interesting to retain a copy of the old .FRX/.FRT for comparison purposes, in case one of the above actually fixes the issue.