Date:  09/14/2011 03:46:09 PM Msg ID:  004334
From:  Jeff Grippe Thread:  004329
Subject:  Re: FW channel crashing script
Here are the answers to your questions:
1. I was doing the test myself and I did not press the refresh button. I was only because I went to the server to try to see what was happening that I noticed that it did eventually finish. The single script did in fact block all the channels (according to the channel status window).
2. Immediately when I restart FW, I see 10 VFP processes in the task manager. I only see 5 on the task bar but I see 10 in task manager.
3. FWStart.log did not reveal anything. I'll email it but I don't think you'll find anything about this script there.
You can see channel after channel go busy when the script execute once FW has ceased to respond correctly to this script. After I restart FW, the script doesn't effect more than one channel and it returns result to the browser in about 1-2 seconds. When the problem is happening, it take many minutes for this script to return results to the browser.
Sent by FoxWeb Support on 09/13/2011 06:28:27 PM:
Just to clarify, are you saying that a single request locks all channels? Is it possible that a single request locks a single channel, but users often get tired of waiting and press Refresh, which would lock additional channels? I have never seen a situation where a single request can affect the ready/busy status of channels, other than the one serving it.
The fact that you are seeing more VFP processes than channels indicates that FoxWeb is having trouble killing and restarting channels. What happens when you stop FoxWeb? Do only some of them go away? Are the rest visible? You may want to make channel windows visible, so that you can see what's going on with them.
You did not mention fwstart.log. Please check it for clues. You can also email it to In this case, please give us an indication of when you had issues, so that we can focus on these time periods.
FoxWeb Support Team email
Sent by Jeff Grippe on 09/13/2011 03:30:39 PM:
FWStart was unrevealing, however, I did notice something strange as I was investigating.
The script does not crash FW but it does do two things:
1. It lock up all the channels (status turns to busy and pending requests start piling up)
2. It takes a really long time to finish and return data to the browser. Once it does finish, all the pending requests get dealt with and all the channels go back to "Waiting"
This will happen every time I run the script until I close and re-open FW at which point, the script will process quickly without locking up channels.
I am not running as a service. I see twice the number of VFP.EXE processes as I have channels (5 channels, 10 VFP.EXE processes). There are no manual VFP sessions. No DW15 or DW20 although I just restarted FW
Sent by FoxWeb Support on 09/12/2011 05:31:42 PM:

Are the channels not restarted after a few seconds? Does fw_start.log contain any useful info, such as channel restart messages? How about the task manager? Count the number of VFP.EXE processes (or fwserver.exe, if you are using the VFP Run-Time DLL). These should be equal to the number of channels you are running, plus any other instances of VFP you have opened manually. While you are there, look for dw15.exe or dw20.exe processes. These would almost certainly be the cause.

One possibility is that the script contains code that intermittently pops up a dialog box (such as the Open Table dialog). If after examining fw_start.log and the task manager you don't find useful clues, you should try running FoxWeb as a regular app (as opposed to a system service), with the channel windows visible (you can do so from the tray icon). Once the problem occurs, examine the channel windows for any visual clues. 
FoxWeb Support Team email
Sent by Jeff Grippe on 09/12/2011 11:45:50 AM:
I have one script (out of hundreds) that seems to periodically crash FW. The script works most of the time but sometimes it locks up all the channels and requires me to restart FW. As soon as I restart FW, it works fine again.
As scripts go, it is one of the simpler ones. It contains two SQL queries and a loop that displays the results in a table.
My two question are:
1. Can you suggest debugging techniques to find it. I realize that intermittent problems are the hardest to find since most of the time, the script works just fine.
2. We are currently on FW 3.0 and VFP 7. Would you recommend and upgrade to  FW 4.5 and VFP 9.0? Other than some queries which will need SET ENGINEBEHAVIOR 70, are there other problems that we can anticipate?