Narrowing down GPF's (Exception 13 or 0x0D)

 

  PRODUCT  :  Borland C++                            NUMBER  :  649

  VERSION  :  All

       OS  :  DOS

     DATE  :  June 17, 1993                            PAGE  :  1/6

    TITLE  :  Narrowing down GPF's (Exception 13 or 0x0D)

    WHAT A IS GENERAL PROTECTION FAULT?

    (ALSO COMMONLY REFERRED TO EXCEPTION 13)

    ========================================

  Protected mode development tools permit much larger programs to

  be compiled faster than their real mode counterparts. They

  accomplish this by allowing the use of a vastly larger memory

  area than is available to real mode tools. There is a cost for

  this increased capability, however; many of us will have to

  change the coding practices and strategies we grew to depend on

  with the relatively tolerant real mode development tools.

  Central to this change  is  the  increasingly  notorious "General

  Protection Fault."   A  GP  Fault  is generated by what one might

  think of as a debugger built into the CPU and is enabled any time

  a program is operating in protected mode.  This debugger-in-a-CPU

  is very, very uncompromising  with  regard  to  the rules which a

  program  must  obey  while  availing  itself  of  protected  mode

  capabilities.

  For  example, suppose a block of memory is allocated for use for

  a particular application, further, suppose another application

  executes an errant read or write outside this block.  In real

  mode this may show up in a variety of more-or-less unacceptable

  ways; many of these we can choose to ignore, sometimes

  manifesting in a computer crash.

  The same program executed in protected mode will, in all

  probability, display a General Protection Fault error message and

  immediately exit to DOS, or issue the following prompt:

    "Terminate, Reboot or Continue?"

  at which point a Reboot at the soonest possible time is advised.

  There is an upside to this, however: any program that runs for

  any length of time in protected mode is likely to be far more bug

  free than an equivalent program executed only in real mode.

    DEVELOPMENT TOOL, DEVICE DRIVER OR APPLICATION?

    ===============================================

  PRODUCT  :  Borland C++                            NUMBER  :  649

  VERSION  :  All

       OS  :  DOS

     DATE  :  June 17, 1993                            PAGE  :  2/6

    TITLE  :  Narrowing down GPF's (Exception 13 or 0x0D)

  Obviously if your applications are going to be subject to GP

  Fault errors it stands to reason that the development tools

  drivers and applications that make use of the extended are of

  memory themselves must abide by the same rules and are subject to

  this  demanding debugger-in-a-CPU.

  It is very likely, however, that some applications or device

  drivers cause GP faults simply because they were not written for

  the protected  mode of the processor.  (For example, hard disk

  controllers, network cards, CD-ROM controllers, etc.) If this is

  the case, it is very wise to make sure that the particular

  application or driver not be loaded high, or to exclude the area

  of extended memory this driver occupies from the particular

  memory manager in use.  In the case of TSR's (Terminate Stay

  Resident) applications, it may be the case that they simply

  cannot exist with other protected-mode applications.

  It is unlikely that any significant program has ever been

  problem-free or could be.  Never the less, as you might expect,

  we are dedicated to eliminating any problem that can be

  identified.  One might guess that this would be an easy task,

  however, often times it is otherwise.

  To the programmer's dismay, the protected mode mechanism does not

  distinguish between problems in the developer's code versus

  problems within the tools themselves.  Consequently, it becomes

  necessary for the developer to take/ additional steps to assure

  that their code is not the actual cause.

  At this point, the developer needs to use some problem solving

  techniques to narrow down the actual culprit.  Does it exist in

  the code being written, another application or development tool

  currently loaded, a conflict in operating system configuration,

  configuration of hardware, or the hardware itself?

  If the General Protection Fault occurred during execution of code

  that you have compiled and are currently executing, you carefully

  want to scrutinize your code.  (See document number 738)  The

  remainder of this document will discuss how to narrow down other

  possibilities of where the GP fault stems from.

  If the General Protection Fault occurs dependably while compiling

  or linking a certain project but not otherwise, it is probably

  PRODUCT  :  Borland C++                            NUMBER  :  649

  VERSION  :  All

       OS  :  DOS

     DATE  :  June 17, 1993                            PAGE  :  3/6

    TITLE  :  Narrowing down GPF's (Exception 13 or 0x0D)

  not your hardware or software configuration.  Try cleaning out

  the Borland configuration files, TCCONFIG.TC, TCDEF.DSK, and

  TCDEF.DPR in the BIN directory for TC or BC, and also remove or

  rename your <projectname>.PRJ and <projectname>.DSK files.  If

  this takes care of the GP fault, you're home free, but if this

  doesn't remove the GP fault, it is probably the result of

  unanticipated errors while compiling or linking, and should be

  reported to Borland (see REPORTING GP FAULTS, below).  In the

  meantime, most reproducible compile-time GP faults can be worked

  around by correcting the error in the code; often reproducible

  link-time GP faults can be worked around by changing the link

  order or removing or rebuilding a corrupted object file or

  library.

    IS IT THE OPERATING SYSTEM CONFIGURATION?

    =========================================

  If it is an erratic GP fault, appearing in the same project

  sometimes and not other times, it is probably the result of the

  way that your hardware and/or software are configured.

  GP Faults generated by OS configuration are not uncommon.  Most

  of them find their cause in the variety of memory management

  standards (or lack thereof) which  characterize  use  of extended

  and expanded (EMS) memory and memory management.

  Since the advent of the IBM PC the industry has progressed from

  the total absence of a standard, as exemplified by IBM's VDISK,

  through VCPI to today's most likely candidate, the DPMI standard.

  However, even DPMI remains unfinished at revision 0.9.

  As you might guess, writing a development tool or application

  which will not clash with any potential use of memory is very

  difficult, if not impossible, to do without an industry-accepted

  memory standard.

  To resolve these inevitable incompatibilities, the user is at the

  mercy of the contending utilities.  If they can be manually

  configured to avoid conflict, the problem can be resolved;

  otherwise, the user must assure they they are never loaded at the

  same time.  Many modern memory management utilities (e.g., QEMM,

  386^MAX, EMM386) provide the options necessary to resolve such

  PRODUCT  :  Borland C++                            NUMBER  :  649

  VERSION  :  All

       OS  :  DOS

     DATE  :  June 17, 1993                            PAGE  :  4/6

    TITLE  :  Narrowing down GPF's (Exception 13 or 0x0D)

  contentiousness.  Many older utilities (e.g., VDISK) do not.

  (Note that you should have 386^MAX version 6.02 or later).  You

  cannot use a version of DOS prior to 3.31 either.

  To quickly  eliminate  OS  configuration (device drivers, TSR's,

  etc.) as a source of difficulty, simply boot your computer from a

  clean configuration ie: a DOS bootable disk with a minimum

  CONFIG.SYS consisting only of FILES=20, BUFFERS=20, and an

  AUTOEXEC.BAT with PATH and PROMPT only.  If a clean DOS bootable

  disk isn't available, rename your system's CONFIG.SYS and

  AUTOEXEC.BAT to something else (e.g., CONFIG.TMP and

  AUTOEXEC.TMP)  and reboot your computer.  Please note that this

  clean boot means no device drivers that are not absolutely

  necessary, including your mouse driver.  Yes, believe it or not,

  some mouse drivers do not know how to correctly translate between

  real and protected mode and can cause GP faults.  At this point,

  don't forget to run DPMIINST (in your BIN directory) if you

  haven't already.

  Please note that if you have a SCSI controller for your drives

  you may need a special SCSI driver to run in protected mode.

  This special driver (if needed) should have been provided with

  your SCSI card; in the case of IBM PS/2's, it is called

  DISK386.SYS.

  Now try whatever caused the GP fault before;  if the problem

  persists, contact Borland Technical Support.  (See REPORTING A

  GENERAL PROTECTION FAULT PROBLEM).  If the problem seems to have

  been eliminated, however, you will need to begin the tedious but

  rather undemanding process of identifying the offending

  driver/TSR/memory manager through stepwise restoration of your

  normal operating configuration.  This is done by adding

  statements back to your AUTOEXEC.BAT and CONFIG.SYS one by one

  and running BC/TC/BCC/TCC repeatedly until the GP faults returns,

  in an attempt to find the exact culprit.

    IS IT HARDWARE DEPENDENCIES?

    ============================

  Finally, there are some GP fault problems which stem from the

  computer's hardware.  Often the problem revolves around the

  system BIOS or some unique aspect of the computer's architecture.

  PRODUCT  :  Borland C++                            NUMBER  :  649

  VERSION  :  All

       OS  :  DOS

     DATE  :  June 17, 1993                            PAGE  :  5/6

    TITLE  :  Narrowing down GPF's (Exception 13 or 0x0D)

  There are also cases in which the machine has minor hardware

  problems which are ignored by DOS but show up with the greater

  demands of protected mode.  This is likely to be the case if

  turning off 'Turbo' mode reduces or eliminates the GP-fault

  problems; that would indicate undependable cache memory or main

  memory.

  Some system BIOS's dated 1989 or earlier are not supported, and

  need to be replaced with a newer BIOS.  Companies such as AMI,

  Phoenix, or Microid Research should be able to provide a new BIOS

  for you.

  Don't forget that TC 3.0 and BC 3.x need at least 2 megabytes of

  memory to run; trying to run with 1 megabyte can bring a GP Fault

  from TCC or BCC.

  In addition, some 80x386 and 80x486 based computers having

  special optimizing settings that make use of the extended area of

  memory that the hardware provides.  These include but are not

  limited to ShadowRam, Internal or External Cache, and sometimes

  even faster clock speeds.  These optimizations are set in the

  CMOS, and may need to be disabled to circumvent the problem.

  Note, when testing these options, you will also want to have your

  system booted on a clean configuration, described above.

  Some 'last resort' possibilities are:  try running DPMIRES before

  running BC/TC/BCC/TCC, do SET DPMIMEM=MAXMEM 1000 before starting

  the compiler, try using HIMEM.SYS in your CONFIG.SYS if you

  haven't tested the compiler in that configuration already and try

  starting BC/TC with /e=0 to turn off use of expanded memory.  If

  you run BC/TC under Windows in 386 Enhanced Mode, it will be

  using Windows' DOS extender and not its own, so that may avoid

  some compatibility issues;  if running that way, you should not

  set DPMIMEM but use a Windows .PIF file with locked extended

  memory.

    REPORTING A GENERAL PROTECTION FAULT PROBLEM

    ============================================

  If the problem occurs under a vanilla operating system as well as

  under your normal operating system configuration it is time to

  contact Borland Technical Support.  Borland Technical Support

  PRODUCT  :  Borland C++                            NUMBER  :  649

  VERSION  :  All

       OS  :  DOS

     DATE  :  June 17, 1993                            PAGE  :  6/6

    TITLE  :  Narrowing down GPF's (Exception 13 or 0x0D)

  provides a Problem Report Form (number 1171) that needs to be

  completed and can be uploaded via fax, CompuServe, or to one of

  our bulletin boards.  You'll need to describe your machine and

  (if applicable) include the smallest section of code that can

  produce the GP fault.

  DISCLAIMER: You have the right to use this technical information

  subject to the terms of the No-Nonsense License Statement that

  you received with the Borland product to which this information

  pertains.