System Restore Process in Windows Xp

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 Home version installation. System Restore uses 400mb or 12% of the Hard Drive (whichever is greater) by default. 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.

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 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?

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.)

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.

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.

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 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 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

For more details on this topic please go to www.wintechhelp.com