PRODUCT : Borland C++ NUMBER : 649 VERSION : All OS : DOS DATE : October 22, 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 : October 22, 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 : October 22, 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 .PRJ and .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 : October 22, 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 : October 22, 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 : October 22, 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.