Date:  10/30/2012 03:53:10 PM Msg ID:  004552
From:  FoxWeb Support Thread:  004547
Subject:  Re: Troubleshooting in-process components
The FoxWeb Channel Controller should be able to restart channels that become unresponsive. Just make sure that the Restart Channels in the FoxWeb configuration is enabled. You should be able to test this by opening the Windows Task Manager and killing one of the channel processes (vfp.exe or fwserver.exe, depending on whether you are using the VFP run-time dll), while FoxWeb is running.
If channels get restarted with the above test, but you are still experiencing the problem, the culprit may be the Microsoft Error Reporting Tool. This utility program collects information automatically whenever certain processing stop responding and can send a report directly to to developers, who use the data to address problems and enhance future program versions.
In some cases, FoxWeb is unable to restart channels that time out, because the Windows Error Reporting tool has them locked.  You can determine if you are affected by this problem by opening the Windows Task Manager (Ctrl + Shift + Esc) and looking for instances of dwXX.exe in the processes list ("XX" is the version number of the Error Reporting Tool -- usually "15", or "20").  If you are affected, then it means that one, or more of your scripts are causing an unhandled exception.  In some cases the problem can be traced to specific problems with scripts and or components that these scripts utilize, but in other cases the only solution is to disable the Microsoft Error Reporting tool.
The following information was collected from various sources.  We have not verified whether it solves the problem and, if it does, which versions of the Microsoft Error Reporting tool it applies to.  Please let us know if any of the solutions below have worked for you.
For DW20.exe:
Disabling the Microsoft Error Reporting tool in the Control Panel:
The Microsoft Error Reporting tool can be configured via the Control Panel -> System -> Advanced -> Error Reporting screen.  You can even configure a list of processes for which the Error Reporting Tool will not report.  If you chose to do so, you should select the VFP executable (vfpX.exe, where X is the VFP executable that you have selected in the FoxWeb Control Center).
Microsoft Knowledge Base Article:
Check knowledge base article: Description of the Windows Error Reporting tool (;en-us;841477).
For DW15.exe (VFP 7?):
According to the VFP 7 SP1 Readme file, you can disable it by deleting the two files below:
FoxPro Fatal Error Reporting
Visual FoxPro 7.0 Service Pack 1 includes new support for FoxPro Fatal Error Reporting. When a fatal exception occurs, an error reporting dialog box will appear making it possible for you to send details of the error, including the state of your Visual FoxPro environment, to Microsoft. Reporting is limited to the full development version of Visual FoxPro 7.0 and will not impact your Visual FoxPro 7.0 run time applications. This is the same error reporting system used by Office XP, Visual Studio .NET and Windows XP.  You can disable FoxPro Fatal Error Reporting by removing the DW15.EXE and DWINTL.DLL files from your Visual FoxPro 7.0 root directory. These files are simply copied into this location and not registered by Service Pack 1.
By the way, the DWINTL.DLL is not in the root directory as stated above, but in the 1033 subdirectory. 
FoxWeb Support Team email
Sent by ayn on 10/30/2012 05:07:49 AM:
We are using an in-process component compiled as a DLL and hosted by vfp.  During peak periods the foxweb server will seize and require a restart (channels would become unresponsive beforehand).  We are certain that the custom DLL is causing the problem.  It is instantiated with the createObject() function and is used to provide a string of characters which is marshalled across the COM boundary.

Are there any script techniques or code practices we could use to either isolate the COM so foxweb can handle itself with a channel restart or perhaps configure in the FW environment?

We are also currently looking at using the COM+ component services, to store the COM but still instantiate it the same way within our scripts.  We are hoping this would provide some management of the COM and expose any problems without the foxweb server crashing.

- Windows 2003 SP2 enterprise ed.
- Foxweb 4.6.3
- VFP v7
- IIS 6.0
- No runtime DLL