Black Box 4/BlackBox.cdr/desqview/except13.arj/EXCEPT13.TEC

Text File | 1991-02-26 | 8KB | 155 lines

ID:13 Exception #12 and #13 and QEMM
Quarterdeck Technical Note #142
by Bob Perry and Dan Sallitt

Q: What is an "Exception #12"?  What is an "Exception #13"?


Q: What can be done to prevent Exception #12's and #13's?

     Exceptions are unusual or invalid conditions associated with
the execution of a particular instruction by the 80386 processor
(or higher processors).  The 80386 recognizes several different
classes of exceptions, and assigns a different vector number to
each class. The DESQview-386 memory manager, QEMM-386, has been
designed to capture these 80386 exception vectors and display
them directly to the user.

    Exception #13 is the "General Protection Fault" error.  Any
privileged instruction or any instruction that references memory
can trigger an Exception #13.  It is the most commonly
encountered 80386 fault.

    The two circumstances that can cause an Exception #13 to
occur require very different troubleshooting approaches.  In the
first case, privileged instructions, the Exception #13 could
indicate that a program has violated the protected mode of the
80386 by executing a privileged instruction or I/O reference.
Thus, when the prompt "Terminate, Reboot or Continue?" is issued,
the "Continue" option puts the system back into real mode, and
the program should continue to execute. (After choosing the
"Continue" option, one should not necessarily assume that the
system is stable.  A reboot at the earliest convenient time is
probably wise.)

     It is the second case, instructions that reference memory,
that is far more common to DESQview 386 (and QEMM-386) users.
Here the exception may indicate that an application has a bug, or
that adverse circumstances have sent it out of control.  It has
overwritten its memory partition, and may in fact be running
wild, writing code all over the place.  This situation can occur
with some programs that were written for use on the 8088
processor and may not be usable in the 80386's virtual 8086 mode.

A few other programs may not be compatible with QEMM-386.  In
some cases the problem occurs even without QEMM present (in which
case it manifests itself as a crash instead of an error
message).  What this usually adds up to is that when "Terminate,
Reboot or Continue" is displayed, the user can usually only
"Terminate."

     On a technical level, this overwriting of the memory partition
generally means that a word or a double word value of code has been
written to the last byte of a segment.  The problem or "bug" in
the application program or in the system shows up as an attempt
to wrap the value to the next segment of memory.

     What can the user do to prevent Exception #13's?   Because a
great many problems can result in Exception #13's, it is
sometimes necessary to resort to general troubleshooting
techniques.  The DESQview 386 user should start with two simple
steps: first, run Change a Program and try to allocate more
memory to the application.  Second, the user can try to increase
the protection level of the afflicted window to 3, which will not
remove the source of the Exception #13, but may pass more
descriptive error messages through to the user.

     When Exception #13's are obtained outside of DESQview they
are either caused by applications written for the 80386 protected
mode or they are not.  If the faulting application is written for
the protected mode of the 80386, it is likely that this program
has no VCPI (Virtual Control Program Interface) support.  Since
QEMM-386 is a protected mode program, such faulting applications
cannot be run under QEMM without VCPI.  The user has no choice
but to reboot without QEMM, and contact the developer of the
faulting application to request VCPI support.

     If the faulting application was not written for the
protected mode of the 80386, a good possibility is that the QEMM
user has installed QEMM with the RAM parameter (which is
necessary to LOADHI drivers and TSR's).  In this case the
faulting program may be running in an area of high RAM that
contains a memory conflict.  To correct this problem, the user
may opt to RAM only specific areas of memory, as described on
page 6 of the QEMM-386 manual, rather than to RAM all mappable
areas.  Of course, an area of conflict that is not RAMmed is
still an area of conflict, and may cause problems if another
application tries to map expanded memory into that region.  A
better solution to such memory conflicts might be to use the
EXCLUDE parameter (described on page 5 of the QEMM manual) on the
area in conflict.

     When in doubt about which areas to exclude, the user may
wish to pay special attention to areas that are marked "Rammable"
on the QEMM.COM Type screen, or to High RAM areas in the F000-
FFFF area.  "Rammable" areas are usually adjacent to ROM areas,
and the possiblilty exists that the ROM is slightly bigger than
QEMM could detect and is spilling over into the "Rammable" area.
High RAM areas in the F000-FFFF region are mapped over pieces of
the system ROM that either QEMM or the user have judged not to be
in use.  Obviously, this judgment should be questioned when
Exception #13 messages occur.  The F000-FFFF area should be
scrutinized especially carefully when floppy disk access
generates the exception error.

     The QEMM.COM Accessed screen (also available as the Manifest
QEMM-386\Accessed screen) can give the user valuable hints about
what areas of memory are in use.  To use the Accessed screen,
replace the RAM parameter on the QEMM line in the CONFIG.SYS file
with the ON parameter and reboot the machine.  Any area that the
Accessed screen then shows as having been touched, but that the
Type screen shows as Mappable or Rammable, is a good candidate
for exclusion.  If the Exception #13 error only occurs with the
RAM parameter present, you can now safely perform the action that
usually generates the error, then consult the Accessed screen to
see what areas of memory have been newly touched.

    Some pieces of hardware can come into conflict with QEMM or
DESQview and generate Exception #13 errors.  The most frequent
offenders are bus-mastering devices (hard disk controllers,
network cards, CD-ROM controllers, etc.) and autoswitching video
cards.  Bus-mastering hard disk controllers often cause Exception
#13 errors upon any use of the LOADHI programs, for instance.
For approaches to this problem, see the Quarterdeck Technical
Note titled "Bus-Mastering Devices and QEMM-386."  Not all
autoswitching video cards come into conflict with QEMM or other
pieces of software.  When a conflict occurs, however, it does not
always take the form of a video problem, and sometimes results in
the Exception #13 message.  Disabling autoswitching is the only
solution to such a problem.

    General troubleshooting methods, like temporarily removing
all TSR's, device drivers and questionable QEMM parameters, often
provide valuable information about the exception error.  It
sometimes happens that a circumstance that generates an Exception
#13 with QEMM present simply causes the machine to crash without
any message when QEMM is removed.  In such a case, QEMM is simply
the bearer of bad news.

     Exception #12 is the "Stack Segment" fault.  The stack
segment fault occurs when the processor detects certain problems
with the segment addressed by the SS segment register.  This
exception too can be the result either of a bug in a program or
of some system malfunction that eventually results in a stack
error. All of the above methods of troubleshooting Exception #13
messages should also be used when trying to track down the cause
of an Exception #12.  The one difference that should be kept in
mind is that Exception #12 messages are not generated by an
application simply going into protected mode, executing
privileged instructions, or accessing privileged registers.
Therefore you need not consider the possibility that the
application needs to incorporate VCPI support to run with QEMM.

        Copyright (C) 1991 by Quarterdeck Office Systems
             * * *   E N D   O F   F I L E    * * *