6
|
|
6 |
|
|
The LA Fox Developer Newsletter
|
|
July 1994
|
|
[Ed. Note: This article is the first in a
three-part
series dealing with General Protection Faults. The author makes no guarantees as to the effectiveness of any of the suggestions and is not liable for any damages which may result from implementing these suggestions, because of the technical nature of the following discussion.
This article is divided into three parts: The Obvious, The Not-So-Obvious, and The Really Obtus This first installment deals with The Obvious.]
Windows
is a very complex and sensitive environment. And probably nothing is more singularly frustrating than receiving the following message:
This can be particularly unnerving after spending 2-1/2 hours, or more, on a screen only to have this message appear.
To understand the nature of this beast, you first have to know what you’re dealing with. General Protection Faults (“GPF”s) are caused by a portion of an application’s memory allotment vying for space with
Windov’/s
memory allotment in RAM, or trying to overwrite a portion of protected memory. Think of it as a “memory collision”. Occasionally, a GPF will also be accompanied by a “Menu manager internal consistancy error’. This can be further complicated by third-party drivers. These drivers can be video cards (or more precisely, the RAM on video cards), network cards, terminate- stay-resident (TSR) programs, and a host of others. And there’s no easy way out of this problem. (I tried the latest version of
WinProbe
and this program caused a GPF of its own.)
When
Windows
issues a GPF, you need to shut
|
down the application (if
Windows
doesn’t do it for you), shut down
Windows,
and, finally, shut down the computer (that’s right, turn it off). This provides only a temporary solution, since an unresolved GPF can reoccur
at any time
during the execution of a
Windows
program. And it seldom occurs at the same memory address. In the above example, the same message occurred at 205F:A093, 205F:OFEC, 218F:A093, and 205F:BOF8 memory addresses.
What is needed is a systematic approach to isolating and resolving this problem. After hours on the phone with
FoxPro
support personnel (and receiving numerous faxes), local phone calls to Microsoft/Irvine, and reading a number of
Windows
texts, I haven’t come up with a bullet-proof isolation, but I’m beginning to get a pretty good handle on it. By the way, this procedure isn’t for the faint-of-heart or those with little patience. The following methodology has the potential for saving you a great deal of time, which translates into billable hours. It is provided purely as a
guide
, since each computer offers its own set of unique characteristics. It also assumes you’ve got the necessary FILES and BUFFERS levels set high enough. (As a minimum, Microsoft suggests 90 and 60 respectively.) It also assumes that you’re running some flavor of DOS 6.xx.
Before undertaking this adventure, make sure you have a system for identifying any changes you may make to file statements along the way. With
DOS
files, I find that following the “rem” with a series of asterisks (*) helps a lot. For instance, all the changes I make on a specific day will have “rem
*‘I
and on a different day will have “rem
***".
And if the editing is particularly convoluted, I’ll even place the revision date in a “rem” statement (with a brief explanation) immediately preceding the modification. The semi-colon (;) in
Windows
serves the same purpose as “rem” in
DOS.
It’s really not important how you do it, just
you do it, and you’re consistent with conventions. It also helps to print out the following files ahead of time:
(This has an added benefit in that you now have a
hard copy of these files in their original state, before
revision.)
|
|
Page 6
|
|
|
6 |
|