Recently I stumbled upon an interesting issue with System Restore in Windows 7 and I would like to share my experience how I solved the “seemingly” unexplainable behaviour of the system and how usually when facing an issue, we miss the forest for the trees.
I have never used System Restore myself but a lot of folks find it useful for a quick revert to previous system state when they experience significant performance decrease after a certain Windows update for example.
You can enable System Restore in Control Panel>System>Advanced System Settings>System Protection>System Restore
In Microsoft's own words "System Restore helps you restore your computer's system files to an earlier point in time. It's a way to undo system changes to your computer without affecting your personal files, such as e‑mail, documents, or photos.
Sometimes, the installation of a program or a driver can cause an unexpected change to your computer or cause Windows to behave unpredictably. Usually, uninstalling the program or driver corrects the problem. If uninstalling doesn't fix the problem, you can try restoring your computer's system to an earlier date when everything worked correctly.”
Ok so far, the difference between system restore and – let’s say full – backup being that system restore will only restore system settings /reverting to an earlier point in time/ and not touching your user data, thus taking less time and hassle than completely restoring from an update.
This again was the case when a friend of mine called me recently to ask why he would not see any automatic restore points, created in the last several months and would have only a few, triggered by system changes like installing Windows updates or other software. He was used to have regular checkpoint in XP/Vista and was wondering why Windows 7 would not create automatic restore points as it should be.
I then firstly looked into the available restore points of my own Windows 7 Pro Machine /Lenovo T420/ to find out that there were some, triggered by installation of software and some automatic:
However, given the fact that my laptop is on every day, it seemed odd to me that an automatic restore point was created twice in almost three months /I looked into it on 17th May/!
I checked again with the official statement from Microsoft and found out that “System Restore in Windows 7 creates a scheduled restore point only if no other restore points have been created in the last 7 days.”:
I had only 3 installations in these three months, so I would expect a lot more automatic restore points created automatically based on above rule. So what happened here?
I checked out Google first and stumbled upon this thread, suggesting different remedies, including repair of system files using sfc /scannow:
Before troubleshooting corrupted Windows system files and dig deeper, I decided to see how automatic restore points are actually created in Windows 7. No surprise, like other maintenance tasks in Windows, automatic restore points are created by a built-in scheduled task called “SR” in Task Scheduler> Microsoft \ Windows \ SystemRestore. I took a closer look at how the scheduled task is configured.
There were 2 default triggers for the task, causing it to run on start-up and at 12:00 AM daily:
As described in a lot of articles, the trigger at start up is delayed for half an hour in order to not additionally slow down the boot process:
Nothing special with the setting of the other trigger either:
Then in the conditions of the task I stumbled upon the following:
So task scheduler won’t execute the task if both conditions are not cumulatively met: the PC should have been idle for at least 10 minutes and should be plugged in. The second condition is especially important when using a laptop, which was the case at hand. This condition applies to both triggers and having in mind people’s habits by using the machine, there was no wonder that the task was actually never executed in the past months!
So the issue was actually a "by design" feature....
I then suggested a slight change of the conditions to match user’s behaviour or completely removing the automatic restore point task, replacing it with manual restore point creation whenever needed /note that removing the SR task does not affect creation of other restore points triggered by a software installation etc./
A)Running the task manually /to workaround the automatic triggering that never happens due to the default condition/
The SR task actually executes a command with certain switch: rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation:
To test functionality of the command, I ran the task manually from task scheduler and additionally executed the command in an elevated command prompt to check if an automatic restore point will be created.
When the task is ran manually, the task completion was logged in the history of the task:
When running the action “rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation” from command prompt, no event was logged, but the action was indeed triggered.
The action will create an automatic restore point only if no other restore points have been created in the last 7 days, as the rule applies to the service call “rundll32.exe /d srrstr.dll,ExecuteScheduledSPPCreation”.
B) Creating a restore point manually (regardless of the fact whether a restore point has been created in the last days or not)
Creating a manual restore point can be done from the GUI:
Or with the Powershell cmdlet “checkpoint-computer”, which is a good option if one would opt out the scheduled task in favour of scripting: