MS-DOS 6.22 Application Crashes Bypassing Interrupts

MS-DOS 6.22 relies on the 16-bit real-mode architecture of the x86 processor family, meaning it lacks memory protection, privilege rings, and preemptive multitasking. When an application crash bypasses standard system interrupt vectors—such as hardware exceptions, CPU fault vectors, or the DOS critical error handler (INT 24h)—the operating system possesses no supervisory mechanism to detect, intercept, or recover from the failure. Consequently, the operating system does not actively "handle" the crash; instead, the processor continues executing corrupted execution paths until it enters an unrecoverable hardware state, leading to a hard system lockup that necessitates a physical reboot.

Real-Mode Execution and the Lack of Isolation

MS-DOS 6.22 runs exclusively in real mode, where all code executes with unrestricted hardware access across the entire 1 MB address space. Unlike protected-mode operating systems, there is no separation between user-space applications and kernel-space operating system routines. MS-DOS does not run as a continuous background supervisor; it functions essentially as a library of interrupt-driven services that yields total control of the CPU to the running binary.

Because of this architectural model, the operating system depends entirely on the processor's Interrupt Vector Table (IVT), located in the first kilobyte of memory (0000:0000 to 0000:03FF), to manage unexpected behavior. If execution goes awry without hitting an explicit software or hardware interrupt, DOS has no runtime monitoring thread to intervene.

Scenarios That Bypass the Interrupt Vector Table

Several common crash conditions fail to invoke standard interrupt handlers:

  • Instruction Pointer Runaway into Data: A wild pointer or corrupted stack can cause the instruction pointer (CS:IP) to jump into regions containing arbitrary data. The CPU decodes raw memory bytes as machine instructions. As long as these random bytes map to valid x86 opcodes and do not generate a hardware trap, execution proceeds aimlessly without triggering an exception.
  • Corrupted Interrupt Vector Table: Misbehaving code that writes to low memory can overwrite the interrupt vectors themselves. If pointers for critical vectors like INT 00h (Divide by Zero), INT 06h (Invalid Opcode), or INT 21h (DOS API) are overwritten with garbage addresses, any subsequent exception jumps to invalid code rather than the intended error handler.
  • Execution of CLI Followed by an Infinite Loop or HLT: If a crashing program clears the interrupt flag (CLI) to disable maskable hardware interrupts and subsequently enters an infinite loop or executes a Halt (HLT) instruction, the CPU stops processing the system timer (INT 08h) and keyboard input (INT 09h).

The Resulting System State

When an application bypasses the interrupt mechanism, the outcome is determined entirely by hardware behavior rather than OS logic:

  1. Hard Lockup (Freeze): If interrupts are disabled or the stack segment (SS:SP) becomes entirely invalid, the machine becomes unresponsive. The display remains frozen on the last rendered frame, and the keyboard buffer stops accepting input.
  2. Spurious Memory Overwrites: The CPU may continue executing garbage instructions, writing random values across conventional memory, device memory (such as video RAM), and DOS internal data structures until the processor halts.
  3. Triple Fault and Spontaneous Reboot: If an operation causes an exception that the CPU cannot resolve through the corrupted descriptor or vector table, modern x86 chips running in real mode typically trigger a reset line, causing the entire computer to instantly reboot without warning or error logging.

Recovery Mechanisms

Because MS-DOS 6.22 has no internal watchdog or process boundary enforcement, automated recovery is impossible once interrupt-driven execution fails.

If the keyboard interrupt vector (INT 09h) remains uncorrupted in memory and the interrupt flag is enabled, a user can initiate a warm reboot via the Ctrl+Alt+Del keystroke sequence processed by the ROM BIOS. If the crash has corrupted INT 09h, altered BIOS data areas, or halted the processor with interrupts disabled, software-level input is ignored entirely. In this state, the only resolution is an external hardware intervention: pressing the computer's physical reset switch or cycling the power supply.