The LA Fox Developer Newsletter

July 1994

Traversing the GP Fault

by Barry R. Lee

[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 effective-

ness 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 Obvi-

ous, The Not-So-Obvious, and The Really Obtus

This first installment deals with The Obvious.]

Windows is a very complex and sensitive environ-

ment. 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 man-

ager 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 prob-

lem. (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 numer-

ous 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) immedi-

ately 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.)

(Con't, page 7)

Page 6