2

Background: FoxPro legacy ERP application on 2012R2

We have a legacy ERP application that we need to keep running for 6 more months. The ERP application was itself written in FoxPro, a discontinued Microsoft product. The FoxPro environment is single-threaded by design and cannot be extended to be multi-threaded. By extension, any programs written in the FoxPro language will also be inherently single-threaded; the ERP application "fakes" threading by doing processing for a single window at a time, using whatever window has the focus. While we can modify the software (it comes with source code) there is not now nor will there ever be a method for safely multithreading a FoxPro program, which is the suggested way to deal with a similar problem in Stackoverflow. This is not an issue that can be resolved by programming.

Running on 2008R2 not an option

The application is being run on a Server 2012r2 installation using Citrix for terminal services; while the vendor for the ERP application recommends running Server 2008/2008r2, it is not possible to run 2008 as

  1. we were unable to upgrade for (long and convoluted) reasons I can't go into and
  2. Microsoft no longer actively sells 2008, nor is there a reputable retailer where we can obtain the product. So we are forced to use this environment.

The application is not published, only the desktop.

Error behavior

With that background out of the way, the problem is simple: the application is randomly "crashing out", by disappearing from the user's session. There is no fatal error dialog, there is no crash message, there is nothing. It simply vanishes. I've managed to trace this to the application being unresponsive for extended periods of time, which for FoxPro is actually normal; when you run a large query in the language the interpreter can stop responding for tens of seconds. Apparently 2012R2 believes that FoxPro has crashed as a result, and automatically closes the program. This is not a desired behavior, we want the application to complete its long running queries and resume normal operation.

This supposition is supported by (sanitized) event log entries such as this:

The program XXXX.exe version 0.0.0.0 stopped interacting with Windows and was closed. To see if more information about the problem is available, check the problem history in the Action Center control panel.
 Process ID: 3810
 Start Time: 01d1c0d181b3e14e
 Termination Time: 4294967295
 Application Path: \\{server}\{ERP share}\{ERP install directory}\XXXX.exe
 Report Id: 1a2c27bb-2cd5-11e6-80f2-141877520cd8
 Faulting package full name: 
 Faulting package-relative application ID: 

The Question

How do we get Server 2012r2 to NOT automatically close a legacy application in a short period of time because it appears "frozen", when it is just busy?

Some not completely fitting registry options

I have found the following registry entries, but none of them seem to apply to the situation (unless, of course, one of them actually does but MS once again failed to fully document it, not like that hasn't happened before):

FYI, just so everyone understands the delays involved, the longest running query I've had to run in FoxPro was approximately 8 minutes. So whatever the answer, it should accommodate the possibility of no response for up to 8 minutes.

2
  • You wrote Apparently 2012R2 believes that FoxPro has crashed as a result, and automatically closes the program. What points in that direction? Does perfmon /rel show an entry for that time? Is the problem reproducible? Does it also happen if you run FoxPro on full published desktop instead of as a published app (which I'm assuming you are running now). Jun 7, 2016 at 6:47
  • I forgot to include that we are not publishing it as an app - for even more reasons I won't bother with, the install is "app adverse" and goes for full desktop each time. I'll amend the question. Jun 7, 2016 at 17:41

0

You must log in to answer this question.

Browse other questions tagged .