Warm Reboot Semantics: BIOS Reset Flags, INT 19h, and DOS State

“Warm reboot” is often used as if it meant one universally defined software operation. On IBM-compatible PCs, the term can refer to a firmware reset path that preserves some state, skips some POST work, and then resumes boot selection. It is not the same as calling BIOS INT 19h, which invokes the bootstrap loader service without necessarily reinitializing the whole machine. Neither path guarantees that DOS buffers, caches, network state, or device hardware have been safely shut down.

The familiar BIOS Data Area word at physical address 0040:0072 is part of a particular PC-compatible reset convention. Phoenix’s System BIOS reference identifies 1234h as a flag to bypass the memory test, also described as warm boot, on the documented AT BIOS. That source also identifies other reset flag values for its firmware family. These values are not a portable application API and should not be written casually from a running DOS program.

The reset flag is firmware input

On systems that implement the documented convention, firmware examines the reset flag during POST. The 1234h value signals the warm-start path and allows the BIOS to bypass a memory test. It does not mean every initialization step is skipped, and it does not prove the machine retained every hardware state safely. Other values can mean different firmware actions; do not generalize a Phoenix or AT data-area field to all PC clones.

The location and value should be described as a BIOS-owned reset indicator, not as a DOS variable. DOS may be running with memory managers, TSRs, device drivers, disk caches, and redirectors whose state is not summarized by the reset word. Writing a value there does not flush them, close files, stop a drive, or safely detach a network stack.

If a forensic tool reads the word, it should record the raw value and BIOS identity. A value of zero or another number does not automatically mean a bug. Firmware can clear or reinterpret the field as part of its own startup process, and alternate BIOS implementations may use a different reset method.

INT 19h is a narrower operation

INT 19h is the BIOS bootstrap loader service. Calling it asks the firmware path to attempt boot selection/loading, but it is not equivalent to a complete hardware reset or a full POST. A DOS session may still have resident handlers and drivers installed, device controllers configured, or cache state awaiting a flush. Starting a new boot sequence over those components can leave the machine unstable or corrupt data.

An application should not use INT 19h as a general restart shortcut. If the requirement is to restart or power off, use the supported DOS, driver, APM, extender, or platform mechanism and follow its shutdown contract. If the only available method is a platform reset, make that dependency explicit and test the exact machine. Never imply that the interrupt resets hardware just because the boot sector is read again.

Warm, cold, and software reset are different observations

A warm reset often preserves power and may skip memory testing or other POST actions. A cold power cycle removes power and may cause a fuller initialization, but the exact behavior depends on hardware and firmware. A software request may simply invoke a boot path, while a keyboard-controller reset or chipset reset may take a different route. These choices can expose different failure modes and should not be used interchangeably in a diagnostic report.

For example, a clock that survives Ctrl+Alt+Del has only shown that backup power persisted during a warm restart. A disk controller that works after a cold boot but not after a warm reset may have a reset-sequencing issue. A machine that restarts into an OS without flushing a write-back cache can lose data regardless of the reset mechanism’s name.

Safe shutdown before restart

Applications should complete ordinary DOS work before requesting a reset: close file handles, flush application buffers, use documented commit operations when needed, and ask active cache/redirector/device software to synchronize through its own API. These steps reduce risk but cannot turn an unsupported reset sequence into a guaranteed clean shutdown.

Do not write 1234h to 0040:0072 and jump to a reset vector from a general DOS utility. That procedure depends on BIOS implementation, CPU mode, interrupt state, and the environment’s ability to unwind memory managers and protected-mode software. A DPMI application must use its host’s documented transition. A TSR may have no safe way to perform a process-wide shutdown at all.

Testing should use a disposable VM snapshot or a machine whose storage can be restored. Record whether the test was a shell restart, BIOS bootstrap call, keyboard reset, warm system reset, full power cycle, or emulator reset. Observe whether caches report clean shutdown, whether DOS vectors and drivers are reinitialized, and whether the next boot passes hardware checks. Do not infer firmware behavior from an undocumented reboot utility.

Capture the test’s pre-reset state: open-file count, cache dirty/clean indicator if available, loaded TSR list, active network session, BIOS drive mapping, and last disk status. After reboot, verify checksums of representative files and inspect filesystem consistency on an image or read-only checker. A successful return to a prompt is not enough; boot code may run even when a driver failed to release hardware or a pending write was lost. Use the same image and boot profile for warm and cold comparisons so a changed disk layout or driver order does not confound the result.

Recovery and diagnosis

If a warm reboot loops, fails to detect a drive, or returns to a partial DOS environment, stop repeating it. Capture the BIOS version, reset path, firmware messages, active memory manager, TSRs, cache/redirector drivers, and storage model. Compare a controlled cold boot to isolate which layer depends on reset behavior. Preserve important data before changing BIOS reset settings or driver order.

When analyzing a reboot tool, determine whether it calls INT 19h, writes a BIOS data-area flag, invokes a keyboard-controller command, resets the machine through an extender, or requests a platform power operation. Those are materially different procedures. Read the implementation or source if available, and do not claim “warm reboot” solely from a menu label.

For a controlled comparison, keep firmware settings, boot-device order, DOS image, and resident-driver configuration constant. Record the exact reset mechanism and compare POST messages plus device-driver initialization, not just elapsed time or whether a DOS prompt reappeared. If a controller remains in a stale state only after one path, the repeatable difference is the evidence to investigate; the reset flag alone cannot explain it.

Acceptance checks

For an operational restart procedure, define a supported machine and firmware list; identify the exact reset mechanism; ensure applications and caches have completed their documented shutdown; verify storage integrity after restart; compare warm and cold boot results; and confirm the BIOS reset flag behavior from that firmware’s manual or source. Test failure modes on disposable media and preserve the pre-test image.

For a read-only inventory, log the BDA reset-word value without modifying it, label the target BIOS, and avoid treating it as a historical record of how the current boot began unless the firmware documents that interpretation. For a software product, make reboot an explicit user action and warn about unsaved or cached data.

Warm reboot is a firmware- and machine-specific lifecycle, not a magic DOS command. Distinguish the reset flag from the bootstrap interrupt, distinguish both from a full cold start, and respect the state that DOS drivers and applications own before any restart is requested.

Related:

Sources: