C R A S H
Documentation
PROGRAM EXCHANGE
(303) 440-0786
July 3, 1989
Richard B. Johnson

INTRODUCTION

How many times have you come home from work or school and
found that your BBS system computer has crashed so the sys-
tem was "down" all day? Usually it's a disk-error and you
are left with the "Abort Retry Ignore" prompt and nobody is
there to hit the key.

If you have a computer that functions as a file-server in a
LAN, you've probably been greeted with "The Network's
down.." just as you walked into work.

Since most BBS systems and file-servers are set up so the
AUTOEXEC.BAT mechanism will get the software started upon
boot-up. Wouldn't it be nice if, upon detecting a fatal
error, the system just re-booted? Just like a VAX! If there
was a bad file that kept causing the crash, the system oper-
ator could fix that later. At least the system would be "on-
the-air" and callers would be able to do everything else
except download the bad file.

Sometimes the system will crash for no particular reason at
all. It just goes off into "hyperspace" and you are left
with a screen full of blinking characters. This is usually
caused by a stack-overflow. Often the system just "locks-up"
for no apparent reason at all. This could be caused by poor
timing in an interrupt-service routine of even a cosmic ray.
There are just so many things that can go wrong with a sys-
tem that is supposed to be "on-the-air" 24 hours a day, all
year long, that its surprising that so many are able to
continue in operation as well as they do!
























- 1 -




What CRASH does

CRASH was written to reboot the system if it detects that
something is not right. CRASH has some limitations of its
own which will be discussed first.

o CRASH is an interrupt-service routine. If the inter-
rupt table gets corrupted, CRASH won't ever get a chance to
do its thing.

o CRASH doesn't know everything there is to know about
every program being executed. Sometimes it can't detect if
data is being executed instead of program code. It tries to
find out, but it's not 100 percent sure of anything.

o CRASH doesn't fix anything. When it detects an error,
it just re-boots the system. This is usually good enough to
keep a BBS system "on-the-air", but if the same bad thing
happens again, CRASH will reboot the system again. For in-
stance, if you have a bad sector in a file that is always
opened by your BBS software, the system will crash over and
over again until you get home to abort the operation.

o Only properly-written programs will execute within the
CRASH environment. Most all programs that use well-known C,
Pascal, BASIC, FORTRAN, and other high-level language com-
pilers will execute properly. Beware of programs written in
Assembly. Many of these programs are not written correctly
and will immediately crash! In particular, some amateur
programs execute software-interrupts to see if they have
been initialized! This is like putting a gun to your head
and pulling the trigger just to check if it was loaded!

The correct way, of course, to determine if a TSR that uses
interrupts has been loaded is to check the code pointed to
by the interrupt-table. It is NOT to execute the interrupt
to see what happens! Some persons who get paid for laying
code and call themselves programmers don't know this. There-
fore some "extra-memory" boards can't be used with CRASH,
nor can some device-drivers.

Programs are also not allowed to execute code within 32
bytes of the end of the code-segment. The stack is not
allowed to wrap around the end of the stack-segment, etc.
These things are normally known, but, there is code out
there that will crash the system!

Note that CRASH is written to execute on an IBM-PC/XT/AT or
true clone. If your machine is not a true clone, it is
possible that some of the information presented in the
crash-dump listing will be incorrect.








- 2 -




That's the bad stuff about CRASH. Now the good stuff.

o At every tick of the system clock, CRASH checks the
following things:

(1) Is the stack still in writable memory?
(2) Has the stack overflowed?
(3) Is the program in the correct place in memory?
(4) Are correct opcodes being executed?
(5) Are we attempting to execute data?

o Every time a disk read or write is made, CRASH keeps
track of any errors. If there are more than four consecutive
read, write or verify errors, CRASH will re-boot the system.
This will prevent the "Abort Retry Ignore" syndrome.

o If "runaway" code attempts to execute any software-
interrupts that it hasn't initialized, CRASH will re-boot
the system. Every location on the interrupt table that is
not dedicated to some "standard" purpose points to code
within CRASH that will re-boot the machine. Any program
using these interupts must initialize them first.

o If an attempt is made to execute RAM that has never
contained program or data since boot-up, the system will
also be re-booted. This will help constrain a runaway pro-
gram counter. This was added in version V1.02

o If there's a memory parity-error. The system will also
be re-booted. This was added at version V1.03.

o If BBS monitoring is enabled, CRASH monitors the modem
ring-indicator. Should the BBS system fail to answer the
modem after ten rings, CRASH will reboot the system. This
will help prevent "hung" BBS software from keeping the BBS
system "off-the-air". This was added in version V1.15























- 3 -




Installing CRASH


Note:
Version V1.19 provides a new feature that will allow it to
run on "stubborn" machines with many foreign attachments.

Place the file CRASH.CFG in your top directory of the boot-
drive (i.e. C:\ ). This configuration file is used to tell
CRASH which interrupt vectors to intercept. For CRASH to
have maximum effectiveness, it is necessary for it to inter-
cept all the unused interrupt vectors in your machine. You
do not have to figure anything out, the machine will do it
for you.

Boot your machine and load all your usual TSRs. Then, with a
printer connected to the machine, execute CRASH. It is like-
ly that CRASH will immediately crash and write a listing to
the screen and the printer. You can stop the printer after
the first few lines by turning it "off", yes the POWER
switch, this will allow CRASH to quickly reboot your machine
while you look at the listing. The listing will likely say,
near the 6th line:

CRASH-F-UNEXINT, Unexpected interrupt, INT HH

... Where HH are two hexadecimal digits representing the
interrupt number.

Edit the data-file, CRASH.CFG with an ASCII (plain-text)
editor and place a semicolon ";" at the beginning of the
line containing the interrupt number you wish to prevent
CRASH from attaching. If you look at the contents of
CRASH.CFG, you will see that this is all very simple and
self-explanatory.

After you have edited the configuration file, execute CRASH
again. CRASH may or may-not crash. If CRASH crashes, simply
look at the interrupt number causing this crash and edit it
out of the configuration file. Eventually, CRASH will load
without crashing your system.

Now; Load your BBS software and execute all "doors", ex-
ternal protocols, and utilities that you normally use for
BBS operation. If CRASH does not CRASH, you have got it
installed! Otherwise, continue to edit the data-file until
NORMAL BBS operation does not cause a crash.

In your AUTOEXEC.BAT file, BEFORE any other TSR are instal-
led, insert the CRASH filename. If a path has not yet been
established, use the complete path so MS-DOS can find the
file. It is recommended that you use a program that waits a







- 4 -




few seconds after booting before you install CRASH. This
will allow you to control-C out of the batch file if there
is a continuous fatal error. The PROGRAM EXCHANGE
AUTOEXEC.BAT file looks like this:

------------------------------------------------------------
@ECHO OFF
REM * AUTOEXEC.BAT *
BREAK=ON
VERIFY=OFF
PROMPT $p$g $
Set COMSPEC=C:\DOS\COMMAND.COM
Set PCPLUS=C:\PCPLUS
Set TELIX=C:\TELIX
Set LOGFILE=D:\WILDCAT
Set JMODEM=SHUTUP
PATH=C:\DOS;C:\TOOLS;C:\XY;C:\NORTON;C:\TELIX;D:\WILDCAT;D:\
WILDCAT\EXE
C:\TOOLS\AUTOTIME < Set system clock
C:\TOOLS\WAIT 00:00:05 < Wait 5 seconds
C:\TOOLS\CRASH /NOPROG < Load CRASH
. < Continue .... other commands
.
------------------------------------------------------------
The following commands may be entered on the command-line to
disable certain functions.

NOTIME Does not print the time-stamp every hour.
NOPROGRAM Does not show the program being executed.
NODUMP Does not produce a crash-dump with
Ctrl-Alt-Del.
NOTABLE Does not print the interrupt-table contents.
NOMASK Does not print the interrupt-controller mask.
NOSTACK Does not print the stack contents
NOREGISTERS Does not print the register contents
NOPOWER Does not monitor power-failure.
NOBBS Dos not monitor BBS operation.

CRASH/NOTIM/NOPRO/NODUM/NOTAB/NOMAS/NOSTAC/NOREG/NOPOW/NOBBS
... will disable all the printing while still allowing CRASH
to monitor the system and reboot if it finds something is
wrong. Note that you may abbreviate the commands. If NOPOWER
or NOBBS is entered on the command line, CRASH does NOT
monitor any BBS operation or power failure. These two com-
mands not only disable printing, but disable monitoring as
well.


CRASH V1.00 was not intended for use by an interactive user.
It never told you what went wrong so an interactive user
didn't know why his system re-booted! Later versions now
give some helpful information.







- 5 -





Version 1.01 writes a message to the screen, telling what
went wrong. It waits about 5 seconds before re-booting.

CRASH V1.06 Brings some additional features.

o The prompts after a crash have modified to follow the
same format as VAX/VMS. In addition to looking "cute", the
messages confirm what facility produced the error messages.

o If you have a printer attached, the "crash-dump" will
now be sent to the printer as well as the screen.

o The complete contents of all the registers are now
displayed except if there was a disk-error causing the
crash.

o If a disk error caused the crash, the drive, head,
cylinder, and sector that caused the crash will be displayed
as well as the kind of error (CRC, Bad seek, etc.)

o The time of the crash is displayed.

o If an attempt is made to low-level FORMAT a hard-disk,
the system will CRASH and re-boot without touching the hard-
disk(s). Floppies are ignored.

These are examples of the new error messages.

A Disk error causes this crash-dump.

CRASH-I-TIM, time 28-MAR-1989 13:08:29.023
CRASH-I-DISKERR, Disk error, Record not found
SYSTEM-I-EXEPROC, Executing process: C:\CRASH\TEXT.EXE
CRASH-I-DOSFUNC, Last DOS function: 4B (Exec prog)
CRASH-I-DISKPARM, disk parameters : (hex)
Physical drive : 81
Cylinder : 010A
Head : 04
Sector : 0A
SYSTEM-F-FATAL, Fatal bugcheck.
CRASH-I-REBOOT, Rebooting.

















- 6 -





Any attempt to FORMAT a hard-disk causes this crash-
dump. Floppy disks are allowed to be formatted.

CRASH-I-TIM, time 28-MAR-1989 13:08:29.182
CRASH-I-FORMAT, Attempt to low-level format fixed disk.
SYSTEM-I-EXEPROC, Executing process: C:\CRASH\TEXT.EXE
CRASH-I-DOSFUNC, Last DOS function: 4B (Exec prog)
CRASH-I-DISKERR, Disk error, No error occurred.
CRASH-I-DISKPARM, disk parameters : (hex)
Physical drive : 80
Cylinder : 0100
Head : 00
Sector : 01
SYSTEM-F-FATAL, Fatal bugcheck.
CRASH-I-REBOOT, Rebooting.


A runaway program-counter causes this crash-dump.

CRASH-I-TIM, time 28-MAR-1989 13:08:29.231
CRASH-I-RUNAWAY, Runaway program-counter.
SYSTEM-I-EXEPROC, Executing process: C:\CRASH\TEXT.EXE
CRASH-I-DOSFUNC, Last DOS function: 4B (Exec prog)
CRASH-I-REGDMP, Register dump:
AX = 0AF0
BX = 10AA
CX = 001A
DX = 0B00
SI = 0010
DI = 0FF0
BP = 0300
DS = 0CA0
ES = 0CA0
CS = B800
IP = 1FA0
SS = 0102
SP = FFE0
CRASH-I-STKDMP, Stack dump:
FFFE = 0000
FFFC = B80A
FFFA = FFFA
FFF8 = 00A0
FFF6 = 0000
FFF4 = 0000
FFF2 = EEA0
FFF0 = EE0A
FFEE = A70B
FFEC = 1283
FFEA = 0000
FFE8 = 0000
FFE6 = F202
FFE2 = B800
FFE0 = 0102
SYSTEM-F-FATAL, Fatal bugcheck.
CRASH-I-REBOOT, Rebooting.



- 7 -






A spurious interrupt causes this crash-dump.

CRASH-I-TIM, time 28-MAR-1989 13:08:29.982
CRASH-I-UNEXINT, Unexpected interrupt.
SYSTEM-I-EXEPROC, Executing process: C:\CRASH\TEXT.EXE
CRASH-I-DOSFUNC, Last DOS function: 4B (Exec prog)
CRASH-I-REGDMP, Register dump:
AX = 0AF0
BX = 10AA
CX = 001A
DX = 0B00
SI = 0010
DI = 0FF0
BP = 0300
DS = 0CA0
ES = 0CA0
CS = B800
IP = 1FA0
SS = 0102
SP = FFE0
CRASH-I-STKDMP, Stack dump:
FFFE = 0000
FFFC = B80A
FFFA = FFFA
FFF8 = 00A0
FFF6 = 0000
FFF4 = 0000
FFF2 = EEA0
FFF0 = EE0A
FFEE = A70B
FFEC = 1283
FFEA = 0000
FFE8 = 0000
FFE6 = F202
FFE2 = B800
FFE0 = 0102
SYSTEM-F-FATAL, Fatal bugcheck.
CRASH-I-REBOOT, Rebooting.



















- 8 -





Incorrect program or stack location causes this crash-dump.

CRASH-I-TIM, time 28-MAR-1989 13:08:29.283
CRASH-I-PROGRAM, Program counter at B800:24B8.
CRASH-I-STACK, Stack at 1A51:FFE8
SYSTEM-I-EXEPROC, Executing process: C:\CRASH\TEXT.EXE
CRASH-I-DOSFUNC, Last DOS function: 4B (Exec prog)
CRASH-I-REGDMP, Register dump:
AX = 0AF0
BX = 10AA
CX = 001A
DX = 0B00
SI = 0010
DI = 0FF0
BP = 0300
DS = 0CA0
ES = 0CA0
CS = B800
IP = 24B8
SS = 0102
SP = FFE0
CRASH-I-STKDMP, Stack dump:
FFFE = 0000
FFFC = B80A
FFFA = FFFA
FFF8 = 00A0
FFF6 = 0000
FFF4 = 0000
FFF2 = EEA0
FFF0 = EE0A
FFEE = A70B
FFEC = 1283
FFEA = 0000
FFE8 = 0000
FFE6 = F202
FFE2 = B800
FFE0 = 0102
SYSTEM-F-FATAL, Fatal bugcheck.
CRASH-I-REBOOT, Rebooting.



















- 9 -





A memory parity error causes this crash-dump.

CRASH-I-TIM, time 28-MAR-1989 13:08:29.003
CRASH-I-MEMPAR, Memory parity error at 8000:0FE0
SYSTEM-I-EXEPROC, Executing process: C:\CRASH\TEXT.EXE
CRASH-I-DOSFUNC, Last DOS function: 4B (Exec prog)
CRASH-I-REGDMP, Register dump:
AX = 0000
BX = 10F0
CX = 0001
DX = 0000
SI = 0010
DI = 01A0
BP = 0210
DS = 0CA0
ES = 0CA0
CS = 0CA0
IP = 0102
SS = 0CA0
SP = FFE0
CRASH-I-STKDMP, Stack dump:
FFFE = 0000
FFFC = B80A
FFFA = FFFA
FFF8 = 00A0
FFF6 = 0000
FFF4 = 0000
FFF2 = EEA0
FFF0 = EE0A
FFEE = A70B
FFEC = 1283
FFEA = 0000
FFE8 = 0000
FFE6 = F202
FFE2 = B800
FFE0 = 0102
SYSTEM-F-FATAL, Fatal bugcheck.
CRASH-I-REBOOT, Rebooting.

Version V1.08 added routines to send a time-stamp to the
printer once every hour. This will help you find the time
the system crashed even if CRASH was unable to reboot be-
cause it got clobbered. The time-stamp goes only to the
printer. The time-stamp is set by the DOS clock when CRASH
is installed. from then on, CRASH keeps it's own time, inde-
pendent of the DOS clock. It understands day and month roll-
over. It even knows about leap-years. It is more accurate
than the DOS time and displays the time to within one mil-
lisecond.

This version also added routines to detect a power-failure.
Obviously, if the power fails to the computer itself, the






- 10 -




computer will not function. If you have a non-interruptible
power supply, you should connect your printer and computer
to this supply. Connect your modem to a power source that
will fail.

When CRASH is first installed, it looks at every possible
communications adapter port to determine if anything is con-
nected that has it's DSR lead high (anything that's turned
on). If CRASH finds something there, usually a modem, it
will check this once-per-second after its installed. If it
finds that the DTR lead is no longer high, it sends a power-
failure warning to both the screen and the printer. It does
NOT reboot the machine. It only sends a warning with the
time of the failure. When the power is restored, CRASH sends
information about the time it was restored to both the
printer and the screen.

Since CRASH checks the communications adapter ports starting
at the first one, if you wish to not hang-up on a caller
when the power fails, you connect you modem to COM2 or above
and to a source of non-interruptible power. You connect COM1
to a small "plug-in" DC power supply of the kind you get for
running shirt-pocket radios (Radio Shack has them). You con-
nect the negative (-) lead to pin seven (7) and the positive
lead to pin six (6) of the DB-25 connector. This power-sup-
ply is plugged into interruptible power. When power fails,
pin 6 will go low, producing a power-failure warning with
the time of the failure. When power is restored, that fact
will be logged along with the time also. Any power supply
voltage from about 5 volts to 20 volts will work fine. These
connections do not affect hardware flow-control which is
handled through pins 4, 5, and 20.

V1.09 Adds routines to produce a stack-dump as well as the
register-dump. The depth of the stack-dump is limited to 80
words to save printer paper. It would not be practical to
trace a stack-overflow condition from the stack contents and
this is about all that could cause such a large stack.

The printer-output routine is located within the TSR. It
does NOT use any of the built-in functions so it should not
get clobbered during a crash. In the event that the printer
is not turned on or is not connected, the messages will
still be printed to the screen. If the printer is powered
on, but is left off-line, the screen message will be printed
VERY slowly (about one-second per character).

The date and time are kept within the CRASH code. This is
because, in the event of a crash, it is likely that the DOS
system time and date will not be usable. The date and time
are set to system time when CRASH is first installed. From
then on, CRASH maintains its own time and date. The internal







- 11 -




date-time routines "know" about day, month, and year roll-
over and are thus more accurate than DOS's internal time.
Leap-years are even accounted for.

Version V1.12 added code to show the program (process) being
executed during a crash. It also now shows the last DOS
function called by the executing routine. Since there is so
much data now available to dump to a printer, its possible
that most users will want to turn some of it off. Therefore,
now you can select what does get printed!

CRASH/notime/noprogam/nodump/notable/nomask/nostack/noregist
ers/nopower...

...is now a legitimate command-line! This will just print
that a crash occurred and then re-boot the system.

The following "no" commands are implemented:

NOTIME Does not print the time-stamp every hour.
NOPROGRAM Does not show the program being executed.
NODUMP Does not produce a crash-dump with
Ctrl-Alt-Del.
NOTABLE Does not print the interrupt-table contents.
NOMASK Does not print the interrupt-controller mask.
NOSTACK Does not print the stack contents
NOREGISTERS Does not print the register contents
NOPOWER Does not monitor power-failure.
NOBBS Dos not monitor BBS operation.

These commands, entered on the command-line, do not have to
be separated with any delimiters. A space or a "/" is
required after the word CRASH, but everything else may be
jumbled together if you like. The commands may also be
abbreviated.

"CRASH notimenoprogramnostacknopower" Is hard to read, but
CRASH will understand perfectly. You may separate the com-
mands with anything you like.

"CRASH [noti](nopro) {nosta} !!nopow!!" would work just fine
also (marvels of assembly-language, anything goes).

If you have the default printer messages enabled, you can
keep your printer turned off with no affect upon system per-
formance. However, if you have the printer power ON, but the
printer is "off-line" or out-of-paper, there will be a very
long pause in system operation during the time that a mes-
sage would be sent to the printer! Therefore, if you wish to
keep all the messages enabled, but you don't wish to have
them printed continuously, turn the printer power-switch off
to disable printing.







- 12 -





Version V1.15 Added pagination and headings to the listing
file. This keeps the listing much neater. The top-of-form is
set with a form-feed so if you print anything to the printer
while CRASH is logging, a maximum of one page will be out-
of-sequence.

Version V1.19 added code to read a configuration file,
CRASH.CFG during installation. This should allow operation
on many different kinds of clones with many foreign
attachments.

Additional notes:
It is VERY IMPORTANT to load CRASH as the FIRST TSR! If you
load it after some other TSR programs, the system may im-
mediately crash and re-boot! This is because CRASH initial-
izes every location in the interrupt table that is not used
by DOS to point to itself. Any program or TSR may use inter-
rupt locations above 60H for its own use. If a TSR has
claimed one of these locations, you don't want CRASH to take
it away. Instead, you load CRASH first, then the other TSR
will take an interrupt-table location away from CRASH, not
the other way around!

It is assumed that CRASH will be installed in a computer
that is executing application programs that have been de-
bugged. Therefore any attempt to low-level FORMAT any hard
disks is also trapped and will cause a crash-dump and re-
boot. This does NOT prevent the DOS FORMAT which consists of
a long READ of the disk to find any bad sectors, followed by
a WRITE to the directory and FAT.

I'm still looking for additional things to check to deter-
mine if the system has crashed! It is still possible to have
an undetected crash which means your system just sits there
staring into hyperspace until you hit the boot-switch. If
you can think of anything else to "look at" 18 times-per-
second that could detect a crash, please contact me at the
PROGRAM EXCHANGE and I'll add it to the code.




















- 13 -




Using CRASH to find problems

If you've installed CRASH and all your BBS or network pro-
grams execute properly without invoking a CRASH-reboot, then
you've got a properly-configured system that is executing
stable code.

Sometimes this is not the case. You can use CRASH to find
what program is causing problems. This program is very like-
ly the culprit that has been causing your system to go off
into hyperspace on occasion.

(1) Put a copy of CRASH.COM on a bootable floppy disk.

(2) Boot the machine from this disk with no AUTOEXEC.BAT
file and no CONFIG.SYS file.

(3) Set the system time is you have an XT or PC.

(4) Execute CRASH. CRASH should sign-on with no problems.

(5) Change default to your hard-disk.

(6) Type your AUTOEXEC.BAT file to the screen.

(7) Enter each if the commands in your AUTOEXEC.BAT file
until you find the one that crashes the machine.

(8) Reboot the machine from the floppy.

(9) Edit the AUTOEXEC.BAT file to remove the bad command
by inserting a "Rem " before it.

(10) Again, execute each command in the AUTOEXEC.BAT file
until you cause another crash.

(11) Continue until you have removed all the bad commands
from your AUTOEXEC.BAT file. You have now isolated the pro-
grams or TSRs that cause problems.

(12) Copy your AUTOEXEC.BAT file to the floppy.

(13) Copy your CONFIG.SYS file to the floppy-disk. Copy any
device-drivers that the CONFIG.SYS might attempt to install.

(14) Reboot from the floppy. If the machine crashes, then
there's something in the CONFIG.SYS file you have to remove.

(15) Continue in this manner until you have isolated the
programs, device, drivers, or TSRs that cause problems.

(16) Execute your BBS software.







- 14 -





(17) Log-in from a remote terminal and execute all the
external protocols, "windows", and "doors".

(18) If your BBS system works correctly, this is the con-
figuration that you should be using when you are using your
system as a BBS.

If you insist in using the defective software that you have
located, then use it only when your system is being used for
interactive use and CRASH is not installed. You can always
make two (or more) ".BAT" files that configure your system
any way you wish. The default ".BAT" file should be the run
the executes the BBS or network software.













































- 15 -




Finding the reason for a system crash

After you've had your system up for a few days, you may find
that CRASH did its job and re-booted after there was some
kind of error. You can look at the listings and determine
what the possible cause was. Here are some hints.

CRASH-I-MEMPAR, Memory parity error at 8000:0FE0

An attempt was made to access memory that was defective. The
memory location causing the problem is shown. The segment-
value is always of the form "X000" to make it easy to find
the defective memory-bank in the machine.

In the event that CRASH was unable to find the failing mem-
ory location, the location will not be shown. Memory parity
errors are most common in "turbo-clones" where memory access
times are severely limited by the high-speed clock. Some
hobbiest TSR programs disable memory-parity checking so that
"souped-up" clones seem to work. Using these programs can
easily destroy your hard-disk contents.

CRASH-F-UNEXINT, Unexpected interrupt, 1F

The program code executed an interrupt that it had not in-
itialized. This could be caused by a "general-crash" in
which the program got corrupted. Most likely, it is caused
by incorrectly-written software. You can verify the software
that was executed by checking the executing process name in
the listing. The interrupt number, 1F in this case, is shown
on the listing.

CRASH-F-PROGRAM, Program counter at 0000:0380

The program attempted to execute code in low memory. There
is no code to be executed below segment 0040H in IBM-compat-
ible computers. This is all data and stack space. You can
verify the software that was executed by checking the exe-
cuting process name in the listing.

CRASH-F-STACK, Stack at 000F:0001

The stack was below the area used for stack-space. The
stack-segment is never below 40H in IBM-compatible com-
puters. These errors are also displayed when the stack is
not in writeable memory.

CRASH-F-RUNAWAY, Runaway program counter.

The program attempted to execute screen memory or executed
memory that it did not "own". This could be caused by a
stack-overflow but is usually caused by a program leaving







- 16 -




"hot" interrupt vectors when it exits because of some error.
In this case, the program that executed before the current
one is usually the culprit. Most communications programs use
interrupts when they execute. If they properly terminate,
they usually put back the original vectors and mask off the
interrupt controller. However, should the program exit be-
cause of a disk-error, or an operator Ctrl-Break, many pro-
grams, which do not trap these exit vectors, will terminate
without restoring vectors. The very next program to be exe-
cuted will likely cause a crash.

The crash-dump produces a figure of the interrupt-controller
mask. By viewing this mask, you can determine which hard-
ware-interrupts were enabled during the crash.

An interrupt is enabled when there is a "0" in the mask and
it is disabled when there is a "1".

CRASH-I-ICTLMSK, Interrupt mask: 10101100
||||||||__ IRQ0 (INT 08H)
|||||||___ IRQ1 (INT 09H)
||||||____ IRQ2 (INT 0AH)
|||||_____ IRQ3 (INT 0BH)
||||______ IRQ4 (INT 0CH)
|||_______ IRQ5 (INT 0DH)
||________ IRQ6 (INT 0EH)
|_________ IRQ7 (INT 0FH)


In this case, you can see that the following hardware-
interrupts were enabled:

IRQ0 (INT 08H)
IRQ1 (INT 09H)
IRQ4 (INT 0CH)
IRQ6 (INT 0FH)

INT 08 = 1599:001C IRQ0 (clock tick) (*)
INT 09 = 1244:0A75 IRQ1 (keyboard)
INT 0A = F000:FF23 IRQ2 (Reserved)
INT 0B = F000:FF23 IRQ3 (COM2)
INT 0C = 21A0:1254 IRQ4 (COM1)
INT 0D = C800:016D IRQ5 (hard disk)
INT 0E = F000:EF57 IRQ6 (floppies)
INT 0F = 0070:0756 IRQ7 (parallel port)

From the interrupt table above, we can verify the following:

IRQ0 Points to code at 1599:001C. It is pointing to code
within CRASH because there is a "(*)" in the description
column. CRASH displays the "(*)" for every interrupt that
points to CRASH code.







- 17 -





IRQ1 Points to code at 1244:0A75. This is the keyboard
interrupt. Normally the keyboard code is in ROM, starting at
address F000:XXXX, but in this case there is a TSR that has
intercepted the vector so it points to itself.

IRQ2 Points to ROM-BIOS code at F000:FF23. This is the
default. This interrupt has never been used since the system
was booted. If you disassemble the code at this location
with DEBUG, you will notice that is resets the hardware
controller and returns with an IRET.

IRQ3 Points to the same code since it has never been used.

IRQ4 Points to code at 21A0:1254. This is presumably a com-
munications program that is using IRQ4 to communicate with
the communications adapter, COM1.

IRQ5 Points to C800:016D. This is code within the hard-disk
controller.

IRQ6 Points to BIOS-ROM code at F000:EF57. This is a flop-
py-disk interrupt vector.

IRQ7 Points to code at 0070:0756. This interrupt was en-
abled when the DOS "print" command loaded a printer-driver.

A complete listing of all the entries in the interrupt table
is provided in the crash-dump. Some hints about the usual
use of the hardware and software interrupts is also provided
in the right-hand column of the list.

A dump of the stack contents is also provided. The stack-
dump normally starts at the first WORD at the top of the
stack-segment. This is hex FFFE, an even address. Should the
stack be greater in depth than 80 words, the message;

"CRASH-I-DUMTERM, Dump terminated at 80-word depth."

is printed followed by the last 10 WORDS before the stack-
pointer. By checking this stack, it is possible to determine
the history leading up to the crash.

If the stack happens to be on an ODD address, a message
warning that the stack is on a BYTE boundary is also print-
ed. If the program being executed was produced by a high-
level language compiler, this generally means that memory
got corrupted so the stack-contents are invalid. Many assem-
bly-language programs are written with the stack placed on
odd boundaries and they still work okay (although slower
than they could be). It takes two memory-accesses to fetch a
word from an odd boundary so it certainly is not good prac-
tice to put the stack-pointer just-anywhere.






- 18 -































































- 19 -




D I S C L A I M E R

CRASH is provided with no warranty whatsoever. The source-
code is provided so that users may determine for themselves
if it provides a useful purpose. It is possible to corrupt
many files on a hard-disk drive if they are not properly
closed during a fatal system error. CRASH does not close any
files because it has no way of knowing if the disk-operating
system has been corrupted during the crash. It does the
exact same thing as a power-off re-boot. CRASH is in use by
the PROGRAM EXCHANGE BBS system. The PROGRAM EXCHANGE does
daily backups of files.

- finis -













































- 20 -