How Windows XP System Restore Used Filter Drivers

In Windows XP, System Restore introduced a reliable way to roll back critical system state without needing full disk images. It achieved this by pairing a user-mode management service with a specialized, low-level kernel-mode file system filter driver known as sr.sys. By intercepting file modification requests at the I/O subsystem level, Windows XP seamlessly backed up files before they were altered, establishing a continuous, low-overhead safety net for the operating system.

The Role of sr.sys in the Driver Stack

In the Windows NT architecture used by Windows XP, storage operations travel down an I/O stack as I/O Request Packets (IRPs). The System Restore filter driver, sr.sys, attached itself directly above underlying file systems such as NTFS and FAT32.

Because it sat directly in the I/O path, sr.sys inspected every IRP directed at the file system. Rather than intercepting user-space APIs—which could be bypassed by low-level system processes or malicious installers—the driver intercepted native I/O requests like IRP_MJ_CREATE, IRP_MJ_WRITE, and IRP_MJ_SET_INFORMATION (used for renaming and deleting files).

The Interception and Copy-on-Write Process

System Restore functioned primarily on a "copy-on-write" mechanism driven by sr.sys:

  1. Request Interception: When a process attempted to write to, truncate, rename, or delete an existing file, the operating system generated an IRP and passed it down the driver stack.
  2. File Filtering: The sr.sys driver evaluated the target file against an internal list of protected file extensions and paths (defined system-wide in filelist.xml). User data files, such as .doc or .txt, were ignored, while executable files, DLLs, drivers, and registry hives were flagged.
  3. Pre-Modification Backup: If the targeted file was monitored and had not yet been backed up during the current restore point window, sr.sys held the modifying IRP in a pending state.
  4. Archive to the Data Store: The driver, working alongside the user-mode service, duplicated the untouched file to a hidden, protected staging directory inside the volume's System Volume Information\_restore{GUID} directory.
  5. Request Release: Once the original version was safely preserved in the restore store, sr.sys forwarded the pending write or delete IRP down to the underlying file system driver to execute normally.

Optimization and First-Write Tracking

To prevent severe disk thrashing and redundant copies, sr.sys tracked which files had already been preserved during an active restore point.

Once a monitored file was duplicated to the restore repository, the driver maintained an in-memory record (and associated volume catalog) indicating that the file was cached for that specific restore snapshot. Subsequent write operations to the same file during the same session were ignored by sr.sys, allowing subsequent modifications to proceed without recurring performance penalties.

Advantages of the Kernel Filter Approach

By leveraging a low-level filter driver, Windows XP avoided the performance and storage costs of taking entire block-level disk snapshots, which the hardware and software of the era could rarely support efficiently. The driver ensured that file captures occurred synchronously before destructive writes, preventing race conditions that could corrupt the restore archive while maintaining transparent operation for user-mode software.