Windows 3.11 Swap File Growth in Low Disk Space

Windows 3.11 managed virtual memory using swap files to supplement physical RAM, but running low on storage during swap operations presented distinct technical challenges. This article explores how the operating system negotiated low disk space conditions, the differences between temporary and permanent swap files, the configuration settings used to prevent system lockups, and the failure states that occurred when disk space was fully exhausted during dynamic swap file expansion.

In Windows 3.11 running in 386 Enhanced Mode, virtual memory relied on two primary types of swap files: permanent (386SPART.PAR) and temporary (WIN386.SWP). Permanent swap files were static, pre-allocated, contiguous blocks of disk space created via the Control Panel; because their size was fixed upon creation, they never expanded during runtime and were immune to dynamic growth failures. Dynamic expansion applied exclusively to temporary swap files, which grew and shrank based on runtime memory demands from running applications.

To prevent a growing temporary swap file from consuming all available disk storage and crashing the underlying MS-DOS operating system, Windows 3.11 implemented safety thresholds. The primary safeguard was governed by the MinUserDiskSpace setting located in the [386Enh] section of the SYSTEM.INI configuration file. By default, this parameter reserved a minimum buffer of free disk space (typically 500 kilobytes). As the virtual memory manager requested additional clusters for WIN386.SWP, it continuously checked available drive space against this threshold.

When a temporary swap file expanded to the point where available disk space reached the MinUserDiskSpace limit, the operating system halted file growth. Windows 3.11 did not overwrite the reserved safety buffer. Instead, the virtual memory manager simply stopped committing new pages to the disk, capping the swap file at its current size.

Once swap file expansion was blocked, any further allocation requests made by software through Windows memory management APIs (such as GlobalAlloc) failed. Rather than reporting a disk-full error directly, Windows 3.11 reported that the system was out of memory. Users encountered standard system dialogs stating, "Insufficient memory to run this application" or warnings advising them to close existing programs to free up resources.

If free space was exhausted unexpectedly—such as when another application wrote heavily to the drive concurrently, bypassing the virtual memory manager's calculations—the underlying DOS file-write calls failed. In these edge cases, Windows 3.11 suffered from severe instability. The operating system could drop to a character-mode DOS prompt displaying the classic "Abort, Retry, Fail?" error, or trigger General Protection Faults (GPFs) across active programs, frequently requiring a hard system reboot.