MSDN Home >  MSDN Library >  Win32 and COM Development >  Windows XP > 

Microsoft Windows XP System Restore

Bobbie Harder
Microsoft Corporation

April 2001

Summary: This article discusses the System Restore feature of Microsoft Windows XP, which enables users, in the event of a problem, to restore their PCs to a previous state without losing personal data files. (12 printed pages)

Contents

Introduction
Detail
Design Overview
Automatically Created Restore Points
System and Application File Change Monitoring
Restore Process
What's Restored and What's Not
Interoperation with Other Windows XP Recovery Features
Files Monitored and Restored by System Restore
For More Information

Introduction

The System Restore feature of Microsoft® Windows® XP (the operating system previously known as Microsoft® Whistler) enables administrators to restore their PCs, in the event of a problem, to a previous state without losing personal data files (such as Word documents, drawings, or e-mail). System Restore actively monitors system file changes and some application file changes to record or store previous versions before the changes occurred. With System Restore, users never have to think about taking system snapshots as it automatically creates easily identifiable restore points, which allow users to revert the system back to a previous time. Restore points are created at the time of significant system events (such as application or driver install) and periodically (every day). Additionally, users can create and name their own restore points at any time. System Restore has an automatic restore point space-management feature that purges the oldest restore points to make room for new ones, so that a rolling safety net is always kept under the user, enabling the user to recover from recent undesirable changes.

If users experience system failure or another significant problem, they can use System Restore from SafeMode or Normal Mode to go back to a previous system state, restoring optimal system functionality. System Restore will not revert user data or document files, so restoring will not cause users to lose their work, mail, or even browsing history and favorites.

Detail

System Restore is enabled by default and will run upon the successful completion of either the Windows XP Professional or Personal x86 version installation. It requires a minimum of 200 MB of space available on the system partition. If there are not 200 MBs available, System Restore will install disabled and will enable itself automatically once the required disk space is created.

This article will discuss the following topics for consideration when developing applications with the optimal interoperation with System Restore.

  • Design overview
  • System restore components and locations
  • Automatically created restore points
  • System and application file change monitoring
  • Restore process

Design Overview

System Restore monitors a core set of system and application files, recording and sometimes copying states of these files before changes are made. Monitored files include those that are not in excluded directories (My Documents) and that do not have known data file extensions (such as .doc). System Restore automatically creates restore points; no user intervention is required. To create a restore point, System Restore takes a full snapshot of the registry and some dynamic system files. For a list of file extension types, which are included (monitored and restored), refer to the Monitored File Extensions list in the System Restore section of the Platform SDK.

To restore a system, System Restore reverts file changes done to monitored files, recapturing the file state at the time of the selected restore point. It then replaces the current registry with the "snapshotted" one, which coincides with the selected restore point. Some security and dynamic rights and authentication information from the current registry is then copied to the restored registry. The next sections will discuss in-depth how this feature works. To achieve the desired behavior after a restore, application developers should answer the following:

  • Do key application binaries to be protected by System Restore contain extensions consistent with those included in the <include> portion of the System Restore Monitored File Extensions list in the Platform SDK?
  • Are user-editable files, or intended personal data files (for example, .pdf, .xls, .htm) named in such a way that they will not be monitored as included extension types? For example, have you named a file extension .ini that a user can modify as a personal data file? If so, this will impede the perception of your product's performance, as well as cause the user to lose work as a result of a restore. (See the Monitored File Extensions list in the System Restore section of the Platform SDK.)
  • Is there key information stored in the registry which, following a restore, will prevent users access to their personal data files or their application? If so, is there a mechanism by which the user can again download or install an application without having to pay for it again? Or have you specified the registry keys where this information is stored in the registry under hklm->system->currentcontrolset->control->backuprestore->KeysNotToRestore? If the information also resides in files, have you ensured System Restore will not restore these files by calling out hklm->system->currentcontrolset->control->backuprestore->filesnottobackup?
  • Does the installer being used call the System Restore RestorePT.API so that the application's install/uninstall creates a meaningful restore point? (See SRSetRestorePoint in the System Restore section of the Platform SDK.)
  • For backup utilities, does it check the files specified in NTFilesnottobackup and, if listed, not back them up? System Restore datastores should not be backed up and are specified in NTFilesnottobackup. System Restore only monitors on first write, so when backing up files, using the operation "open to backup" will not cause additional overhead from System Restore.
  • Does the backup utility have undo functionality in the event of a cancelled or failed recovery? If not, calling the System Restore API (14-Recovery) will ensure users have a restore point immediately before a recovery so that users can revert an undesirable or cancelled recovery. (See SRSetRestorePoint in the System Restore section of the Platform SDK.)

Figure 1. System Restore components and locations

Automatically Created Restore Points

Restore points are created to allow users to choose previous system states. Each restore point gathers the necessary information needed to restore to a precisely chosen system state. They are created before key changes are made to the system. Since these restore points are automatic, users don't even have to think about creating manual restore points (unless they choose to). The following topics describe the triggers that cause this feature to create a restore point.

Event-triggered restore points

System Restore will automatically create a restore point before the following events:

  • Application installations (provided the application utilizes a current installer that is System Restore RestorePT.API compliant). In the event the application causes harm to the user's system, choosing a restore point before the application was installed allows the user to roll the system state back to the time before the installation of the application, if needed.
  • AutoUpdate installation. The Auto/Industry Update feature of Windows XP provides an easier way for users to download critical Microsoft Windows® updates in an unobtrusive way. Once the update is downloaded, the user is presented with the opportunity to install the update on the user's system. When the user chooses to install the update, the System Restore feature will create a restore point before the actual installation of the update begins. If the user restores after files are downloaded but before the installation of the update occurs, the downloaded files will not be removed by the restore operation.
  • Restore operation. If a user, for example, accidentally chooses the wrong system state to restore back to, the user can, by choosing a restore point before this operation, undo the restore operation. The user can then choose the correct restore point. The restore operation itself will create a restore point for undo purposes.
    Note   Only administrators or owners can restore.
  • Microsoft Backup Utility Recovery. Before Microsoft Backup Utility performs a backup recovery, System Restore will create a restore point. In the event the recovery is cancelled or leaves the system in an undesirable state, users can use this restore point to revert the system to the point before the recovery started.
  • Unsigned driver installation. Unsigned device driver installations are detected by the INF installer of Windows. Before the installation proceeds, a restore point is created so in the event the installation results in a harmful impact to the system, users can restore to the point immediately before the unsigned driver installation.
  • Manual Restore points. At any time, users (administrator/owner users only) may create and name an on-demand restore point. This is useful to create a "checkpoint" to return to preceding a particularly risky change, before a shared system is left to other users, or at a particular state the user perceives to be optimal.

Scheduled restore points

In addition to creating restore points before certain events, System Restore provides users with the ability to restore to other specific days and times. It does this by creating a restore point every 24 hours of calendar time. By default, System Restore will create a restore point every day that the machine is running. These restore points are only created during idle time; for example, when there is no mouse, keyboard, or disk i/o activity. Scheduled restore points saved and compressed (NTFS only) are made available to the user, in the event of a problem, through the System Restore user interface. Also, users have the flexibility at any time to manually create and name a restore point from within the System Restore user interface.

Restore point creation and storage

During the restore point creation operation, System Restore takes a snapshot of the registry and some key dynamic data stores, makes an entry into a restore point log, and saves the registry and datastore copies into an archive. Over time the archive collects multiple restore points, each of which represents the system state at various points in time. These points in time are made visible to the user in the System Restore user interface. The restore point archive of System Restore resides in the system volume information directory, which is a hidden system directory. This archive is protected by the system ACLs in NTFS. Over time the files, registries, and logs associated with older restore points will be purged on a first-in-first-out (FIFO) basis, limiting the amount of disk space used by System Restore and creating sufficient storage space for new restore points.

Figure 2. Restore point creation operation

System and Application File Change Monitoring

In addition to collecting restore points that are associated with specific events and times, System Restore also constantly monitors other key system and application file changes. Tracking these file changes is necessary to fully restore the system to a particular state. This aspect of the feature works to record and, if necessary, preserve a previous file state, which enables the user to restore to a previous system state. This change tracking will not interfere with the user's performance experience.

To track and copy files before changes, System Restore uses a file system filter driver that is at the kernel level (called Kernel Mode). This kernel level filter driver monitors file system operations, and, for select file types and operations, quickly interrupts an operation (for example, DELETE FILE) and copies or moves the original file before the operation is complete. The file changes are entered into a log, and the file copies and logs are stored in an archive on the drive or partition where the original file resided. Change-based file copying happens once per specific file per system session or for any given restore point.

Figure 3. System filter driver file copy operation

Restore Process

As the computer is used over time, restore points are collected in the archive without any management or intervention required by the user. If the user ever runs into a problem and chooses to use the System Restore feature, these various restore points are made visible to the user through the System Restore Wizard user interface. The user can choose to restore to any restore point still stored in the data archive.

When a specific restore point is chosen and the restore process starts, the command is passed to the System Restore Service, which accesses the System Restore change logs. These change logs enable the feature to create a restore map, which intelligently instructs the feature on how to re-create the specific system state the user has chosen. The restore map is then processed, the system restarts, and the original registry and dynamic data stores are replaced.

Figure 4. Restore process

What's Restored and What's Not

Restored

  • Registry
  • Profiles (local only—roaming user profiles not impacted by restore)
  • COM+ DB
  • WFP.dll cache
  • WMI DB
  • IIS Metabase
  • Files with extensions listed in the <include> portion of the Monitored File Extensions list in the System Restore section of the Platform SDK

Not Restored

  • DRM settings
  • SAM hives (does not restore passwords)
  • WPA settings (Windows authentication information is not restored)
  • Specific directories/files listed in the Monitored File Extensions list in the System Restore section of the Platform SDK
  • Any file with an extension not listed as <included> in the Monitored File Extensions list in the System Restore section of the Platform SDK
  • Items listed in both Filesnottobackup and KeysnottoRestore (hklm->system->controlset001->control->backuprestore->filesnottobackup and keysnottorestore)
  • User-created data stored in the user profile
  • Contents of redirected folders

Interoperation with Other Windows XP Recovery Features

Last Known Good

Last Known Good and System Restore features provide a compliment of functionality to assist the user in recapturing optimal state if the machine is ever non-bootable. As described above, Last Known Good provides the ability to boot the system using the subset of registry keys, which were used the last time the system successfully booted. Last Known Good saves off the latest of these keys/values each time the system is successfully booted. When the system detects a failed boot attempt, it will automatically select the Last Known Good option from the F8 menu. Users can also elect to boot from the Last Known Good feature available from the F8 boot menu option. Using Last Known Good, users can usually boot into either the Safe or Protect (Normal) mode of the system. Following booting with Last Known Good, from either Safe or Normal Mode, if users want to revert undesired changes to the system to recapture previous state, they can use System Restore.

System Restore is not available from the Recovery Console, nor does it track changes done in that advanced environment. This means that system changes completed in the Recovery Console will not be monitored nor recoverable using System Restore.

When restoring a system, System Restore will revert Last Known Good state so that it is always consistent with the registry targeted in the restore operation. In other words, the most current Last Known Good keys/values are also reverted so they are replaced with what they were when the target (or restored to) registry was snapshotted by System Restore. This ensures the restored registry and Last Known Good state are always consistent.

Last Known Good should be used when there is a non-bootable state. Once booted into either SafeMode or Normal Mode, System Restore can be used to capture optimal previous state. System Restore cannot be accessed unless the system is bootable into one of these modes.

Driver Rollback

When a driver doesn't work, Windows XP offers Device Driver Rollback capability, which can replace a device driver with the previously installed version. So when a user installs a new device driver that causes system instability, the user merely reinstalls the previous device driver and continues using the system.

System Restore, with its active change monitoring design, captures all monitored file and registry changes made by installing a new device driver. Since driver installations are only a subset of the overall state changes System Restore captures, it should be noted that using System Restore to revert undesirable changes to the system resulting from driver installations will also revert any other changes to the system made since the last restore point was created. For example, suppose a user installed an unsigned driver—the system would create a restore point automatically. Then the user changed their desktop appearance and their dial-up networking settings. Now the user notices the system behavior has degraded. Using System Restore, the user reverts the system to a point before the device installation was done. The system is now restored to the point before the driver was installed, but the desktop appearance and dial-up networking settings changes are also restored. If a Driver Rollback option is not available for the device driver just installed, System Restore may be the best recovery option for the user. If, however, Driver Rollback does provide a means to reinstall the previous driver and the user does not want to revert recent changes made after the driver install, Driver Rollback may be the best recovery option to prevent restoring the desired recent changes, while recovering the previous driver and reinstalling through driver rollback.

Using System Restore, if an unsigned driver installation appears to be the source of undesired system behavior, users can revert their systems to the restore point created automatically just before a driver was installed. In the event the device driver was signed, System Restore would not create a restore point. However, the effects of that device driver installation can still be reverted using System Restore, by restoring to the most recently created restore point before the driver was installed. This will revert changes made to the system by the driver, as well as any changes made after that restore point was created.

System Restore will also revert the driver rollback .INF cache used by Driver Rollback to reinstall the previous driver on the system. This means if you use System Restore to revert an undesirable change, you may temporarily lose the capability to reinstall the old driver using Driver Rollback as System Restore will revert the system to a point before the former driver .INF was saved in the cache. If you are fairly certain a driver installation is the source of your problems, and/or if there are system changes after that install you wish to retain, you should try to use Driver Rollback first to reinstall the previous drivers without reverting other system changes. In the event Driver Rollback cannot reinstall your previous driver, System Restore would be the recovery feature to use to revert undesirable system effects resulting from a device driver installation.

If you have done a System Restore initially and really just want to reinstall the previous drivers without reverting other system changes, you can simply undo the recent restore, then access Driver Rollback to reinstall your previous drivers.

Microsoft Backup Utility

The Backup Utility helps users create and recover a copy of the data on their hard disks. In the event the original data on the hard disk is accidentally erased or overwritten, or becomes inaccessible because of a hard disk malfunction, users can access the copy to recover lost or damaged data. Unlike System Restore, the Backup Utility backs up users personal data files, ensuring a safe copy stored either on the local disk or to another medium. System Restore does not monitor changes to or recover users' personal data files such as documents, drawings, e-mail, and so forth. While system data contained in System Restore's restore points are available to restore to for only a limited period of time, backups taken by the Backup Utility can be recovered anytime.

Before a Windows Backup Utility recovery starts, it calls System Restore to create a restore point. If there is sufficient disk space and if the results of the recovery fail or were unsatisfactory, System Restore can, in most cases, be used to revert the changes resulting from the recovery. Any personal data files recovered will not be restored or removed by System Restore.

ASR

Automated System Recovery (ASR) extends conventional backup-and-restore applications by providing a framework for saving and recovering the Windows XP operating state, in the event of a catastrophic system or hardware failure. Windows XP ASR recovers the target system in a two-step process. The first step, termed the boot recovery process, requires a new copy of Windows XP to be temporarily installed on the target system using the original distribution media. The second step, called the OS restore process, restores the files of a previously saved Windows XP installation using a backup-and-restore application (thus deleting and writing over some of the files installed by the boot recovery process). In the event of a system failure, the ASR can be used to restart the system, after which users can begin a recovery from a backed up copy of a previously saved Windows XP installation.

While System Restore is useful to undo harmful changes to system files, the system must be bootable to either SafeMode or Normal Mode for System Restore to restore these changes. In the event of catastrophic failure, with ASR and a conventional backup-and-recovery application, users can boot the system using the original media and then recover a backed-up previous Windows XP installation. Once a system is recovered, previous System Restore restore points will no longer be available, nor will the restore points associated with the recovered installation. A fully-recovered system via ASR will restart System Restore's monitoring and restore point creation capabilities, just as an upgrade or reinstall of the operating system.

Files Monitored and Restored by System Restore

System Restore applies an inclusionary model to monitor a core set of system and application files, archiving the states of these files before system changes are made. To view the included files specified in System Restore, see Monitored File Extensions in the System Restore section of the Platform SDK. Modifications from sources other than Microsoft will not be supported.

For More Information

For further information on configurable parameters and remote interfaces of System Restore, as well as full documentation on the RestorePt.API, please see the System Restore Start Page in the Microsoft Windows XP Platform SDK.


©2005 Microsoft Corporation. All rights reserved. Terms of Use |Trademarks |Privacy Statement
Microsoft