Microsoft KB Archive/120182

{|
 * width="100%"|

-

The information in this article applies to:


 * Microsoft FoxPro Library Construction Kit, versions 2.5x, 2.6x
 * Microsoft FoxPro for Windows, versions 2.5x, 2.6x

-

SYMPTOMS
When you attempt to load an .FLL file, the second load causes the following general protection (GP) fault error message:

FoxProW caused a General Protection Fault in module KRNL386.EXE at xxxx:xxxx

CAUSE
This problem will occur if WIN87EM.DLL has not been loaded properly.

RESOLUTION
Microsoft has confirmed this to be a problem in the Microsoft products listed at the beginning of this article. This problem was corrected in Visual FoxPro 3.0 for Windows.

WORKAROUND
To avoid this problem, do the following:


 * 1) Keep WIN87EM.DLL always loaded in memory. To have Program Manager (PROGMAN) or another Windows shell keep this in memory, rename WIN87EM.DLL to be WIN87EM.EXE and place WIN87EM.EXE on the LOAD= line of the WIN.INI file.
 * 2) Don't use floating-point operations in the FLL.

MORE INFORMATION
WIN87EM.DLL is the library used to support floating-point emulation in Windows-based applications.

This problem occurs under the following conditions:


 * 1) The FLL created with the FoxPro Library Construction Kit (LCK) uses floating-point math.
 * 2) WIN87EM.DLL is not used by any other applications.
 * 3) The computer has a math coprocessor.

When the FLL is loaded, the startup code runs a routine called fpinit. Within the fpinit routine, an exception handler (code residing in WIN87EM.DLL) is set. The task database of the application using the FLL receives the pointer to this exception handler. During this process, the pointer to the "old" handler is stored. For a new task, the old handler is NULL. Note that loading 0000 into a selector register will not cause a GP fault.

After the FLL is loaded the first time, the task database contains a valid code pointer (valid selector). When the application unloads the FLL (but the application does not exit), the code pointer remains in the task database because the startup code for the FLL does not call fpterm. When the FLL is unloaded, WIN87EM.DLL is also unloaded.

Loading the FLL again at this point will repeat the process of installing the exception handler and reading the "old" handler. The old handler this time is not NULL but rather a pointer to a function in WIN87EM where WIN87EM used to be before it was unloaded from memory the first time. This results in a bad selector load, which causes the GP fault. In addition, if a long time has elapsed between the two times the FLL was loaded, the selector may have been "reused" for something else, causing unpredictable results for the FoxPro application.

The first time FoxPro GP faults, it leaves WIN87EM stranded in memory. The problem only occurs if WIN87EM is also loaded and unloaded with the FLL. Additional query words: VFoxWin FoxWin 2.50 2.50a 2.50b 2.60 2.60a LCK api gpf errmsg fixlist3.00 buglist2.50 buglist2.50a buglist2.50b buglist2.60 buglist2.060a

Keywords         : kberrmsg FxtoolLck Version          : 2.5x 2.6x Platform         : WINDOWS Issue type       :
 * }