Why Vista's System Restore is Dangerous and What to do About it

Recently a colleague of mine had a problem: by mistake he had deleted part of the software registry hive (HKLM\Software) of his Vista machine while trying out some code. When he asked me for help my first thought was to go back to the last System Restore point. But that seemed a bit harsh. It would have restored the registry settings in question. But not only that: System Restore not only captures and restores every single file in the windows directory, it also does that same for a lengthy list of file types on all volumes for which System Restore is enabled.

In the case of my colleague going back to a restore point would have meant to lose all EXE files downloaded, all changes made to batch files (BAT or CMD) or scripts (VBS) and any shortcut (LNK) created. Everything would have been gone.

This was intended by Microsoft. They designed System Restore in Vista specifically to include any potentially dangerous file type so that it could be used as a mechanism to remove malware. The drawback of this approach is that every power user, administrator or developer will lose data when going back to a System Restore point.

Extracting Files From a Restore Point

Now back to the problem at hand. How to get back part of the registry without going back to an earlier system state? As you may know, System Restore in Vista uses shadow copies to do the work of backing up and storing older versions of changed files. Each system restore point basically is a shadow copy. I remembered a series of excellent articles written by Adi Oltean on how to access the contents of a shadow copy. After having refreshed my memory the solution was both obvious and simple:

List all shadow copies:

vssadmin list shadows

This spits out a list that contains the date of and the path to each shadow copy. The paths have a peculiar format like:

\\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3

Copy the required file(s) from the shadow copy to a temporary folder:

copy \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\Windows\System32\Config\Software c:\temp

Dealing With GLOBALROOT Paths

When playing around with those GLOBALROOT paths one quickly notices that most tools do not accept them – this includes Explorer and DIR. If you want to know what is contained in a shadow copy you can use the following mini-script which was inspired by Adi Oltean:

for /r \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3\ %i in (*) do @echo %i

Another way to explore shadow copies is to assign a drive letter to them with dosdev. Dosdev is a little-known tool contained in the Microsoft Product Support Reporting Tools. Download and run MPSRPT_CLUSTER.EXE. This unpacks the tools to %Systemroot%\MPSReports\Cluster\bin and starts a script that generates a system report. The script does not change the system and can be safely terminated.

The following command uses dosdev to assign drive letter R: to shadow copy no. 3:

dosdev r: \\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy3

Now you can use “comfortable” tools like DIR to view the contents of shadow copies. You cannot use Windows Explorer, though. It seems to actively filter out “suspicious” or unknown types of drives. I recommend you use Total Commander instead.

In order to remove the drive letter pointing to a shadow copy use:

dosdev -r -d r:

References:

Adi Oltean’s excellent blog
File extensions monitored by System Restore
Understanding how System Restore in Windows Vista treats executable file