In addition, System Restore automatically writes checkpoints every 24 hours. If a system has been running for more than 24 hours, then a new checkpoint will be written every 24 hours while the machine is powered on.
Some conditions may prevent automatic system checkpoint writing, either passively or on demand. Consider the following circumstances:
Either the System Restore or Task Scheduler services are not running.
System Restore requires the Task Scheduler to be running in order to work correctly (i.e., to create checkpoints automatically every 24 hours). Make sure no application, user or script has disabled either of these services.
The system's CPU was not idle when System Restore was scheduled to run.
System Restore cannot passively write a checkpoint unless the CPU is idle. That way, the System Restore process does not interfere with user activity. If you have software running that continuously uses a high percentage of the CPU and cannot disable it or remove it, make sure it runs in the Idle priority state to keep it from interfering with System Restore.
A condition arose that caused System Restore to suspend operations.
Scenarios for suspended operations include running out of space on a non-system drive on which System Restore has been enabled; or a file monitored by System Restore on such a drive (for example, an unsigned device driver) has been modified. You need to reactivate System Restore by manually running it after you've cleared up the condition in question.
The Event Log Service is disabled.
The specific symptom for this problem is if System Restore locks up when the user attempts to manually create a restore point. (When a restore point is created manually, an event is logged, so if the Event Log service isn't running this obviously creates a problem.)
Be on the lookout for these conditions, and avoid them to keep System Restore working the way it should.
About the Author:
Serdar Yegulalp is editor of the Windows Power Users Newsletter. Check it out for the latest advice and musings on the world of Windows network administrators -- and please share your thoughts as well!
This was first published in June 2005