How MS-DOS 6.22 Handles CONFIG.SYS Driver Failures

During the boot phase, MS-DOS 6.22 parses CONFIG.SYS sequentially, loading device drivers into memory and calling their initialization routines. When a driver encounters an error and fails to initialize, MS-DOS 6.22 relies on specific return codes and pointer offsets provided in the driver's request header to determine that a failure occurred. Instead of halting the system, the operating system reclaims the allocated memory, reports a standard error message to the console, and continues executing the remaining directives in CONFIG.SYS.

The Initialization Call

When MS-DOS 6.22 encounters a DEVICE= or DEVICEHIGH= command, it allocates a memory block (either in conventional memory or an Upper Memory Block via the UMB provider) and loads the binary image into that space. The kernel then issues Command Code 0 (INIT) to the driver's Strategy and Interrupt routines by passing a pointer to an Initialization Request Header via the ES:BX registers.

Failure Signaling Mechanisms

A device driver signals an initialization failure back to MS-DOS 6.22 through two fields in the Initialization Request Header:

  1. The Status Word: Located at offset 03h of the request header. If an error occurs, the driver sets bit 15 (the Error Bit) to 1 and populates bits 0 through 7 with an error code (such as 02h for "Drive not ready" or 0Ch for "General failure"). Setting the Done bit (bit 8) informs DOS that processing has completed.
  2. The Ending Address (Break Address): Located at offset 0Eh (a 4-byte segment:offset pointer). This pointer specifies the end of the driver code that should remain resident in memory. To signal a complete initialization failure, the driver sets this break address to match the starting address where DOS initially loaded it (typically offset 0000h of its assigned segment).

Memory Reclamation

MS-DOS 6.22 evaluates the break address returned in the request header:

  • If the break address equals the driver's base load address, DOS treats the driver as discarded. The Memory Control Block (MCB) allocated for the driver is either resized to zero or freed entirely, returning the space to the free memory pool.
  • If a driver set an error code in the status word but set the break address beyond its base address, DOS keeps the specified portion resident, which is a technique some drivers use to display an error and abort partially while keeping a stub resident.
  • For DEVICEHIGH= directives, if the driver fails in an allocated UMB, DOS frees that specific Upper Memory Block, ensuring the upper memory is available for subsequent TSRs or drivers processed in AUTOEXEC.BAT or CONFIG.SYS.

Console Reporting and Execution Flow

When MS-DOS 6.22 registers an initialization failure:

  • It writes a generic warning to the display, such as:
    Error in CONFIG.SYS line X
    followed by:
    Device driver not found: <filename> or an internal driver-supplied text message if the driver printed to standard output before exiting.
  • The system does not crash or trigger a Kernel Panic. MS-DOS treats device initialization failures as non-fatal exceptions.
  • The kernel closes any open file handles associated with the driver binary and proceeds immediately to the next configuration directive in CONFIG.SYS.