Windows 3.11 Shutdown and Disk Cache Flushing

Microsoft Windows 3.11 relied on a coordinated multi-stage process between the Windows graphical environment, protected-mode virtual device drivers (VxDs), and underlying MS-DOS disk utilities to flush write-behind caches during system shutdown. Because Windows 3.11 was an operating environment executing on top of MS-DOS rather than a standalone operating system, exiting the system required orderly termination of active applications, flushing internal 32-bit caches, signaling real-mode TSRs like SMARTDrive, and cleanly restoring CPU control back to the MS-DOS real-mode environment.

The Role of Write-Behind Caching in Windows 3.11

In the Windows 3.11 era, disk read and write caching was primarily handled by two components: Microsoft SMARTDrive (SMARTDRV.EXE) or the 32-bit File Access subsystem introduced in Windows for Workgroups 3.11.

Earlier versions of SMARTDrive only performed read caching, but version 4.0 and later implemented write-behind (delayed write) caching. This meant that file modifications were held in memory buffers and written asynchronously to the physical drive seconds later to improve performance. Windows for Workgroups 3.11 introduced 32-bit File Access, utilizing VFAT.386 and VCACHE.386 to bypass both MS-DOS and the BIOS, maintaining its own protected-mode dirty cache buffers. Without a strict shutdown flush routine, cutting power or instantly rebooting would cause severe file system corruption.

Phase 1: Application-Level Shutdown

When a user selected "Exit Windows" from the Program Manager, the Windows USER module initiated the standard cooperative multitasking shutdown sequence:

  1. WM_QUERYENDSESSION Broadcast: The system sent this message to all running top-level windows. If any application returned FALSE (such as a word processor prompting the user to save unsaved files), the entire shutdown sequence was aborted immediately.
  2. WM_ENDSESSION Broadcast: If all applications responded affirmatively, the system sent WM_ENDSESSION with the flag set to TRUE, notifying applications that Windows was terminating and that all local files and handles should be closed.

Closing application file handles triggered internal file-close calls down through the file system stack, flushing application-level buffers to the active cache layer.

Phase 2: VxD Termination and 32-Bit File Access Flushing

After standard Windows applications closed, the system began shutting down 386 Enhanced Mode:

  1. Device Power and System Exit Notifications: The Virtual Machine Manager (VMM) broadcast a series of system control messages—notably Sys_VM_Terminate and Device_Exit—to all loaded 32-bit Virtual Device Drivers (VxDs).
  2. VCACHE and VFAT Flush: When VCACHE.386 and VFAT.386 received the shutdown notification, their exit handlers scanned all cache blocks marked as "dirty" (data written in memory but not yet committed to disk).
  3. Physical Write Execution: Using direct disk controller drivers (such as WDCTRL for Western Digital-compatible IDE controllers) or the protected-mode *int13 driver, the cached data was physically written to the drive's sectors.
  4. Subsystem Teardown: Once all buffers were verified as written, 32-bit File Access released its low-level disk hooks, safely handing drive I/O control back to the standard MS-DOS and BIOS routines.

Phase 3: Returning to Real Mode and Signaling SMARTDrive

Once the 32-bit environment was dismantled, Windows transitioned the CPU from protected mode back to real mode to return to the MS-DOS command prompt:

  1. Multiplex Interrupt Signaling: If the machine was using SMARTDrive instead of or alongside 32-bit File Access, Windows issued an MS-DOS Multiplex Interrupt (INT 2Fh) using function AX = 4A10h with subfunction BX = 0001h. This was the documented API to command SMARTDrive to immediately flush its cache buffers to physical storage.
  2. Interrupt 13h and 21h Trapping: SMARTDrive, which resided in conventional or upper memory as a resident program (TSR), intercepted this interrupt, stepped through its internal write-behind queues, and issued BIOS INT 13h write commands to ensure all sectors reached the disk controller.
  3. Restoration of MS-DOS Control: Windows executed an exit routine that unloaded WIN386.EXE (or KRNL386.EXE), restored original interrupt vectors, and transferred control back to the parent COMMAND.COM instance.

With all protected-mode and real-mode dirty buffers written to physical media, the user was left at a standard DOS prompt (C:\>) where it was safe to either power off the computer or restart the machine.