How Windows XP System Restore Monitored Drivers

Windows XP introduced System Restore to protect system integrity by rolling back system files, drivers, and the registry to previous states without affecting user documents. At the core of this architecture was a dedicated kernel-mode file system filter driver named sr.sys, working in tandem with the user-mode System Restore service (srservice). To monitor driver installation events, Windows XP combined high-level installer notifications with low-level file interception, capturing driver binary modifications via copy-on-write mechanisms and logging them into distinct restore points.

The Role of the sr.sys Filter Driver

The sr.sys driver was loaded into the file system driver stack above the base file systems (such as NTFS and FAT32). By sitting directly in the I/O path, sr.sys could inspect all I/O Request Packets (IRPs) sent to the storage subsystem, such as IRP_MJ_CREATE, IRP_MJ_WRITE, and IRP_MJ_SET_INFORMATION.

Rather than tracking every file on the system, sr.sys filtered events based on an internal ruleset governed by a system configuration file (filelist.xml). This list designated critical system file extensions and paths for tracking, explicitly including core driver and installation assets such as .sys, .dll, .inf, and .cat files located in directories like %SystemRoot%\System32\drivers and %SystemRoot%\Inf.

Intercepting Driver File Changes via Copy-on-Write

When a driver package was deployed, the installer attempted to write new binaries or overwrite existing ones. The sr.sys filter driver handled these events using a copy-on-write mechanism:

1. Interception: When a process initiated a write or delete request for a monitored driver file, sr.sys intercepted the IRP before it reached the underlying file system.
2. Duplication: If the targeted driver file already existed, sr.sys created a backup copy of the original file and placed it into the active restore point directory located within the hidden System Volume Information\_restore{GUID}\RPx folder.
3. Change Logging: The filter driver recorded the operation in a change log (change.log) associated with that specific restore point. This log detailed the original file path, the backup file name, and the specific operation performed (modification, deletion, or creation).
4. Execution: Once the backup and logging were completed, sr.sys allowed the original IRP to continue down the driver stack, completing the driver installation or replacement on disk.

Coordination with SetupAPI and PnP

While sr.sys operated continuously at the kernel level to catch file modifications, driver installations were formally categorized through user-mode coordination.

Driver installations conducted through the Plug and Play (PnP) manager or installer packages typically utilized the SetupAPI subsystem. Before committing changes to disk or modifying the registry, SetupAPI issued an explicit call to the System Restore API using the SRSetRestorePoint function. It passed the BEGIN_SYSTEM_CHANGE flag along with the DEVICE_DRIVER_INSTALL restore point type.

This call instructed the user-mode service to initialize a new, labeled restore point. As the driver files were copied and the corresponding registry keys under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services were created, sr.sys directed all associated file change logs to this specific restore point. Once the installation concluded, SetupAPI called SRSetRestorePoint with the END_SYSTEM_CHANGE flag to finalize the snapshot, ensuring that the driver could be cleanly uninstalled or reverted in the event of hardware instability.