>Hello Al,
>thank you very much for your reply. I tried to check all step by step and what I have is:
>
>Both VFP500.DLL and VFP5ENU.DLL are 5.0.0.415 and they are in C:\Windows\System32.
>No duplicates, no older versions on this computer.
>
>We use FPROT antivirus on all our computers, not doing manual scan and do not have any problems with it.
>
>Motherboard BIOS and all drivers are Up-to-date.
>We do not use AIO printers.
>
>I was able to reproduce the problem on my dev machine just once with the same pure information.
>All other tries did not give me a crush.
>
>The user who has the problems has her own computer which is brand new.
>She is the user who mostly works with AR part of SBT.
>All other parts of SBT like IC, SO, PO work pretty well for different users on different computers
>
>Problem machine is basic and does not have any add-on hardware.
>
>We do not use OmniPage at all.
>
>The fault address I gave in my posting is just an example, it's not every time the same.
>I have 0x002bc2e1 (faulting module vfp500.dll), 0x00011d8f (faulting module ntdll.dll),
>0x00011e58 (faulting module ntdll.dll), but mostly 0x000109f9 (faulting module ntdll.dll).

Hmm, it sounds like you're doing everything "right". Just to confirm:

- Regarding AV, I'd be most concerned about the real-time scanning component. Is that configured to not scan VFP files/folders?
- Does the user have OmniPage *installed*, even if it's not being used?
- I just noticed your network is Novell. Are you using an up-to-date network stack for Novell, and are you sure it's configured the same way on the problem machine as the others that are working OK?

I've also just noticed your company name. Is it a manufacturing plant? I've seen cases where large electrical loads in the plant were causing electrical spikes and noise in attached offices, and causing reliability problems and outright hardware failures in computers. Or, the company next door may be doing arc welding etc. Or, maybe in your office there's a heavy-duty photocopier that runs intermittently? Basically, anything that could degrade electrical power quality. Does the problem computer have a UPS (not just a surge-suppressing power bar)?

Probably the only other thing specific to that user is her physical network connection (patch cable, wiring to switch, switch port). Maybe you could try plugging in the problem machine at a different physical location/network connection, with a different patch cable. Or temporarily run a long patch cable to another wall jack or switch port for testing purposes.

VFP5 is old and has some bugs. It's possible the AR portion of SBT encounters one. As a final test, you could have the user do her AR work on one of the other ("stable") computers in the office to see if the problem recurs. Don't move the other computer, leave it exactly as-is. If it does, you may just have to accept that that combination of SBT/VFP5 crashes once in a while in VFP5.

I'm trying to recall if, with SBT, you get full source code. If so, you could potentially try recompiling in a newer version of VFP to see if that makes any difference.