Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Thursday, October 13, 2016 3:22 AM
I have system restore enabled on my PC. Restore points are being created on a regular basis(even if there were no installations/updates done). In Task Manager, under the SR task, I see the last run time, which matches the time of the last restore point created. However, there are no triggers defined for the SR task. How does it get launched? There are other tasks that also have no triggers, but do have a last run time.
All replies (9)
Thursday, October 13, 2016 3:52 AM
Event-triggered restore points
System Restore automatically creates a restore point before the following events:
- Application installation (provided the application utilizes an installer that is System Restore compliant). If the application install causes system problems, the user can restore the system to a state before the installation of the application.
- AutoUpdate installation. AutoUpdate provides an easy way for users to download critical Windows updates. After the update is downloaded, the user can install the update on the system. If the user chooses to install the update, System Restore creates a restore point before the installation of the update begins.
- System restore. For example, if a user accidentally chooses the wrong restore point, the user can undo the restore operation by choosing a restore point before the system restore took place. The user can then choose the correct restore point.
Arnav Sharma | http://arnavsharma.net/ Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Thursday, October 13, 2016 4:04 AM
Unfortunately, I don't *think* that's it. When there is an app installation, or a windows update, the restore point description indicates it.
Thursday, October 13, 2016 4:52 AM
Hi Arto,
It's something of a misnomer to think of this as a scheduled task, as from a practical standpoint, it's not.
This "scheduled task" is actually called by an external process and is therefore no different to you coming along and manually choosing to "run it now". You can see this reflect in the "History" tab where you will see it's actually being called by the SYSTEM account and has the task category of "Task triggered by user".
Cheers,
Lain
Friday, October 14, 2016 3:07 AM
Hi Arto Bas,
We could check the Event Viewer(Applications and Services\Microsoft\Windows\Task schedule) for more information of the trigger. Or just check the running "history".
Best regards
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Sunday, October 16, 2016 10:12 PM
I enabled the task scheduler history a few days ago. The entries do not indicate (at least to me) what triggered the task to run. It ran yesterday morning, and the first task ID shown in the history is 325(??). Event log shows that I logged in a few minutes earlier. The restore task launched but didn't create a new restore point(since it had not been 7 days since the last one). That said, there is no entry in the history for today. I logged in several hours ago, but the task was not triggered. Thus I must assume that logging in is not what triggers it.
Monday, October 17, 2016 8:53 AM
Hi Arto Bas,
We also could check the Event Viewer(Applications and Services\Microsoft\Windows\TaskSchedule) for the trigger(Pay attention to the timetamp).
Best regards
Please remember to mark the replies as an answers if they help and unmark them if they provide no help.
If you have feedback for TechNet Subscriber Support, contact [email protected]
Friday, October 21, 2016 4:44 AM
OK, so in the event log, I see that the Task Scheduler launched the SR task. Happened a bit after another login. Still doesn't tell me what triggered it. There must be information about this somewhere...
Friday, October 21, 2016 8:04 AM
Events or time-based triggers are indeed explicitly listed. Some quick examples are:
- A task triggered on a time-based schedule will log an Event ID = 107.
- An event-triggered task (such as firing off a logged Event Log event) will log an Event ID = 108.
- A task called by an external process - which includes you running it manually, will log an Event ID = 110.
This has all been covered already.
If you do not have a defined trigger in the Triggers tab then there's a very good chance you should be checking for instances of event 110, for which you can find the calling user in the event details, as described above.
Beyond this, if you want to find out more about the calling process then you're going to have to look at different areas of Event Viewer as anything from a service to a manually-executed process could be calling it.
That said, since you're talking about the SystemRestore category, you might want to check the System node in Event Viewer and see if there was any Windows Update installations happening around that time, give or take a few minutes.
Ultimately though, it's up to you to figure out what the calling process (or user) might have been doing as there's no scope within the log for the Task Scheduler itself to have such a deep understanding about what the calling process is trying to achieve in the bigger picture. It's just there to do what its told.
Cheers,
Lain
Friday, October 28, 2016 4:22 AM
Well, I have a 325 event under Application and Service logs|Microsoft|Windows|Task Scheduler|Operational that indicates that an instance of the SystemRestore\SR task was queued up about 12 minutes before the timestamp of the restore point. However, the entry does not indicate what actually triggered it. The user indicated was System. The same info is shown in task scheduler history.
I could not find any 110 event, 107 event, nor a 108 event anywhere near that time.
I guess there is something hard coded & buried somewhere to launch the SR task.