How MS-DOS 6.22 Handles RAM Parity Errors

When hardware detects a RAM parity error while running MS-DOS 6.22, the operating system does not attempt error recovery; instead, the hardware triggers a Non-Maskable Interrupt (NMI), prompting the system to immediately halt execution and display an error message. This article explains the technical chain of events from hardware detection to the CPU freeze, the specific on-screen messages generated, and the safety rationale behind the abrupt system crash.

The Trigger: Hardware Parity Detection and NMI

Older personal computer architectures, such as the 386, 486, and early Pentium systems typical of the MS-DOS 6.22 era, used 30-pin or 72-pin SIMM memory modules equipped with dedicated parity bits. For every eight bits of data, a ninth bit stored parity information.

When the memory controller read data from RAM and calculated a mismatch between the stored parity bit and the computed parity of the retrieved byte, it signaled a hardware-level fault. The memory controller asserted the x86 CPU’s Non-Maskable Interrupt (NMI) pin. Because the interrupt is non-maskable, the processor stopped executing current tasks immediately, regardless of software flags.

MS-DOS 6.22 and the Interrupt 02h Handler

MS-DOS 6.22 is a real-mode operating system without memory virtualization, process isolation, or advanced hardware error handling. When the CPU receives an NMI, it immediately looks up Interrupt Vector 02h (the dedicated NMI vector) in the interrupt vector table (IVT).

Unless a third-party memory manager (such as HIMEM.SYS or EMM386.EXE) or a custom Terminate-and-Stay-Resident (TSR) program hooked Interrupt 02h, execution fell directly back on the system BIOS NMI service routine. Under standard MS-DOS 6.22 execution, neither the DOS kernel (MSDOS.SYS) nor the BIOS attempted to isolate the corrupted memory address or resume execution.

The Visual Response: Parity Check Messages

When the NMI handler took control, it cleared system registers and wrote a text-mode message directly to the screen via the video BIOS or direct video memory access. The exact text depended on the motherboard's BIOS manufacturer (such as AMI, Award, or Phoenix), but common messages included:

  • PARITY CHECK 1: Indicates a parity error located on the system board (motherboard) RAM.
  • PARITY CHECK 2: Indicates a parity error located on an expansion bus card or add-on memory board.
  • RAM PARITY ERROR - SYSTEM HALTED: A generic BIOS message indicating corrupted system memory.

The Fail-Safe Halt

After outputting the error message, the NMI handler executed a CLI (Clear Interrupts) instruction followed by an HLT (Halt) instruction inside an infinite loop:

cli
halt_loop:
    hlt
    jmp halt_loop

This effectively locked the computer. The keyboard stopped responding (except for hardware reset buttons or the power switch), sound output ceased, and all disk I/O stopped instantly.

Why MS-DOS Halts Immediately

The abrupt lockup was a deliberate design choice rather than an operating system flaw. Because MS-DOS 6.22 operated with direct access to hardware and used the FAT16 file system, allowing execution to continue with corrupted RAM carried a severe risk. If the corrupted memory held disk buffers, directory structures, or File Allocation Tables, continuing to run could result in writing corrupted data to the hard drive, destroying entire partitions. A hard lockup preserved data integrity on storage media at the expense of unsaved volatile data.

To recover from a RAM parity error in MS-DOS 6.22, the user had to perform a hard reboot or cycle the power to the machine.