FIX: General Protection Fault When .FLL Is Loaded Twice
ID: Q120182
|
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:
- 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.
- 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:
- The FLL created with the FoxPro Library Construction Kit (LCK) uses
floating-point math.
- WIN87EM.DLL is not used by any other applications.
- 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 :
Last Reviewed: July 30, 1999