Thanx for all the suggestions.

I have discovered that my sporatic lockup problem was caused by a serious bug in VFP5&6 which MS aware of, and I had not even contemplated. The details are in KB Q183522, which is an interesting/important read.


The story goes like this:

Once upon a time there was a developer who lost his mind...

I finally found a combination of commands that would cause client machines to crash. Fortunately I was working on a Win98 machine, which instead of just locking gave me the following blue screen:
< FATAL EXCEPTION 0D... IN VXD VMM...
and then after about 45 seconds that blue screen was replaced with:
< CAN NOT READ FROM DRIVE C:...
FYI: I could not get Win95 clients to crash using the same keystrokes that caused the Win98 machines to crash. I thought that there were no useful error messages because by the time the a crashed user had dragged me back to their station, the blue screen had changed to CAN NOT READ FROM DRIVE C:.

Anyway, MS Fox support called me right when I was logging into the MS KB so they did the search for me and found Q183522.

Basically the prob relates to VFP not handling the Math Co-Processor properly, so I turned off all of clients math co's (via DEVICE MANAGER) and I have not had a crash in 30 hours. The prob now of course, is that many programs including Win98 REALLY REALLY want the math co. so, as per Q183522, I will have to add DECLARE command to reset the math co, AFTER EVERY PRINT COMMAND.

Once again, thank you all!

_____________________
>>I have had an app running for 2+ weeks without any serious problems, and then late last week, the app started to hang users machines. It appears to happen only when a user presses a button that results in them changing to a different form.
>>
>>While the machines can lock at almost anytime, they usually lock after a few hours of use. They either hang (i.e. CNTL ALT DEL, does nothing) with the HDrive light on (although I have not been able to hear the HDrives grinding away as I would expect), OR the CAN NOT READ FROM DRIVE C: blue screen appears. Either way the user has to power down their machine.
>>
>>Typically when a user clicks a button to go to another form, the code looks something like:
>>< CLOSE tables all
>>< CLOSE databases all
>>< Clear windows
>>< DO FORM XXXX.SCX
>>
>>I also have a form in which I used:
>>< thisform.release
>>instead of the CLEAR WINDOWS line but the same hang prob occurs on that form.
>>
>>All forms:
>>run maximized;
>>without any menus;
>>with a FIXED DIALOG Boarder Style;
>>in the VFP main screen which is sizable with scroll bars;
>>
>>I thought it might be related to the DB, so I have a VALIDATE DATABASE, PACK DATABASE routine that is now run every night. But this has not helped.
>>
>>I have also changed all of the UPDATE settings to IGNOR in the Referencial Integrity. Now there is only CASCADE set for some of the DELETE settings in the RI.
>>
>>All clients have at least 48MB running either Win95 or Win98, pulling the shared data from an NT server (I just upgraded to SP4 from SP3 but had no improvement) with 128MB. The server is almost exclusively for File and Print sharing (i.e. no apps running on the server). All the client HDrives are fast, have at least 300+MB free, and have been scan disked and defragged in the last week or so. The client machines are all Intel P150's or better, running brand name parts.
>>
>>All my forms use Pessimistic Row Buffering, and I have "editwork c:\
>>tmpfiles c:\, sortwork c:\, progwork c:\" in the CONFIG.FPW file.
>>
>>No other programs are having problems sharing data on the server and no other programs a locking users machines.
>>
>>My VFP has SP2.
>>
>>I am out of idea's and getting VERY worried. Any sugguestions would be greatly appreciated.
>Hi Ian,
>I second on Robert's suggestion. Never set tempfiles to root dir. Root dir has filecount limit (it was 512 in old days but don't know if changed). When FP cannot use a temp dir then you can get any errors in response to even "quit".
>Tempfiles = "c:\temp" && Useless - discards \temp and sets temp file to c:\
>Instead use editwork, progwork, sortwork as you do :
>editwork = c:\temp\
>sortwork = c:\temp\
>progwork = c:\temp\
>\Temp must exist and the second backslash is for compatibility with fox2x (in fox2x c:\temp is treated as c:\).
>Also if you do not use local tempfiles you could get file read errors on an NT server.
>There was a thread about this few days ago and the solution :). You cannot do a search too I know but that's all I have :(
>Cetin