Windows 95 Defrag and Background Disk Scanning

Windows 95 introduced a built-in graphical Disk Defragmenter capable of operating inside a preemptive multitasking environment, allowing users to work while their hard drives reorganized. Because active programs could simultaneously write to the disk, the utility relied on real-time background monitoring and repeated allocation scans to verify data integrity. This article explains how Windows 95 monitored disk activity, interacted with the file system layer, and managed conflicts caused by background processes during defragmentation.

The Shift from MS-DOS to Multitasking

In MS-DOS, defragmentation utilities (such as MS-DOS 6's DEFRAG) ran in exclusive single-tasking mode. The system froze all other operations, ensuring the File Allocation Table (FAT) and cluster maps remained static throughout the procedure.

Windows 95 transitioned defragmentation into a Win32 application that operated alongside active background processes, system services, and user applications. This shift required a mechanism to prevent the defragmenter from moving data to sectors that another application was concurrently reading or modifying.

Real-Time I/O Monitoring via IFSMGR

Windows 95 handled background disk scanning by interfacing directly with the 32-bit Installable File System Manager (IFSMGR.VXD) and the underlying virtual device drivers (VxDs).

Instead of locking the entire volume—which would freeze the operating system and prevent multitasking—Disk Defragmenter registered hooks with the file system to monitor write requests. While the defragmenter read the drive structure and organized files contiguously, IFSMGR tracked any disk I/O requests directed at the target volume:

  1. Cluster Mapping: Disk Defragmenter initially scanned the FAT16 (or later FAT32) allocation table to generate an in-memory cluster map showing used, free, and fragmented space.
  2. Drive Activity Interception: As the defragmenter prepared to move a block of clusters, the operating system monitored for any concurrent INT 21h write calls or direct disk write requests.
  3. Change Detection: If any background application, system log, virtual memory swap file (WIN386.SWP), or hidden task wrote data to the disk, the file system flagged that the volume's allocation state had changed.

The Invalidation and Rescan Cycle

When a disk write occurred, the in-memory map held by Disk Defragmenter became obsolete. To prevent data corruption, such as overwriting newly created files or cross-linking clusters, the defragmenter discarded its current progress on that section of the drive.

The utility then triggered an automatic background rescan of the drive's allocation structures. Users routinely observed this process via the graphical cluster map, accompanied by the status message: "Drive's contents changed: restarting."

The defragmenter did not necessarily restart the entire drive optimization from zero percent, but it was forced to pause, reload the FAT, verify the integrity of the clusters it intended to move, and recalculate its optimization path before resuming data transfers.

Practical Limitations of Background Scanning

Because Windows 95 constantly updated timestamps, managed system caches, and expanded the dynamic swap file, routine background tasks often triggered continuous rescans. Common culprits included:

  • Screensavers: Animated screensavers with write cycles interrupted the scan loop.
  • Antivirus Scanners: Background scanning agents reading and writing temporary log files.
  • Network Tasks: Incoming packets or shared network drive requests forcing local disk writes.

Due to this aggressive rescan mechanism, defragmentation often became stuck in an infinite restart loop until the user manually disabled background software, closed open applications, or restarted Windows 95 in Safe Mode where background disk writes were minimized.