Other answers require 3rd-party software or a running task/service, and many have to be repeated after Windows updates. This solution has several advantages:
- It's fast & easy: Just a single cmd command
- It's permanent: No need to repeat after Windows Updates
- It's lightweight: No running services or tasks required
Solution
Run this command in Command Prompt as administrator:
cd C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator && rename Reboot Reboot.backup & rename Reboot_Battery Reboot_Battery.backup && rename Reboot_AC Reboot_AC.backup && mkdir Reboot && mkdir Reboot_Battery && mkdir Reboot_AC && copy NUL Reboot\empty_file && copy NUL Reboot_Battery\empty_file && copy NUL Reboot_AC\empty_file
Edit 2020-09-15: Check out the update at the bottom of this answer.
Backup solution (in case of access denied error)
This command first gives Administrators ownership of and full permissions to the UpdateOrchestrator folder & contents.
cd C:\Windows\System32\Tasks\Microsoft\Windows && takeown /F UpdateOrchestrator /A /R /D y && icacls UpdateOrchestrator /reset /T /C && icacls UpdateOrchestrator /T /C /grant *S-1-5-32-544:F && cd UpdateOrchestrator && rename Reboot Reboot.backup & rename Reboot_Battery Reboot_Battery.backup && rename Reboot_AC Reboot_AC.backup && mkdir Reboot && mkdir Reboot_Battery && mkdir Reboot_AC && copy NUL Reboot\empty_file && copy NUL Reboot_Battery\empty_file && copy NUL Reboot_AC\empty_file
What it does
Automatic reboots after updates are performed by Windows Tasks, specifically one of Reboot
, Reboot_AC
or Reboot_Battery
. These tasks are defined in files in the C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator
folder.
This solution renames these files and creates folders with the same names in their place. It then puts an empty file in each of the created folders.
This effectively deletes the tasks responsible for the auto-reboots, and prevents Windows from re-creating them.
Why it works
Windows can no longer run the Reboot
, Reboot_AC
or Reboot_Battery
tasks after an update because they no longer exist (except as backups with different names).
When this happens, Windows will attempt to fix the problem by re-creating (or fixing) the expected tasks (files), and then run them. However, Windows will fail to create the needed files because there's a folder with the same name in the target folder and two items in the same folder can't have the same name.
Moreover, since folders and files are different things, Windows will not be able to modify the folders into files containing the correct Task definitions.
Finally, because the command puts an empty file in each of the created folders, it's very unlikely that they will be automatically deleted (making it possible to re-create the tasks). This is because deleting folders with contents requires a recursive delete command, which would never be used for deleting something expected to be a file.
For these reasons, this solution is much more robust than those relying on changing file ownership/access and/or modifying the relevant tasks, something that can be (and frequently is) "fixed" by Windows during updates.
Sources & testing of the solution
I learned about the technique used in my solution from this article. I have been using this technique for several years and have not experienced a single auto-reboot in all this time except this January (2020) when Microsoft added the new Reboot_AC
and Reboot_Battery
tasks, which are now also used by Windows Update to initiate automatic restarts.
I have updated the solution myself to account for the new tasks, and it has successfully prevented reboots after the changes I've made.
The entire answer, including the cmd commands, is my own original work.
Update 2020-09-15:
@Simon East comments that a new task, USO_UxBroker
just triggered a reboot on his system. The task description (This task triggers a system reboot following update installation.
) seem to confirm the purpose of this task. I haven't tested the effects of also nuking this new task, so I will leave it up to the reader to decide if it's worth trying out. Please leave a comment if you have any info about USO_UxBroker
. (Did it cause a reboot of your system? Did the updated solution prevent a reboot for you? Did the original solution prevent a reboot despite USO_UxBroker
being untouched?)
Command that includes the USO_UxBroker
task:
cd C:\Windows\System32\Tasks\Microsoft\Windows\UpdateOrchestrator && rename Reboot Reboot.backup && rename Reboot_Battery Reboot_Battery.backup && rename Reboot_AC Reboot_AC.backup && rename USO_UxBroker USO_UxBroker.backup && mkdir Reboot && mkdir Reboot_Battery && mkdir Reboot_AC && mkdir USO_UxBroker && copy NUL Reboot\empty_file && copy NUL Reboot_Battery\empty_file && copy NUL Reboot_AC\empty_file && copy NUL USO_UxBroker\empty_file
In case of access denied error:
cd C:\Windows\System32\Tasks\Microsoft\Windows && takeown /F UpdateOrchestrator /A /R /D y && icacls UpdateOrchestrator /reset /T /C && icacls UpdateOrchestrator /T /C /grant *S-1-5-32-544:F && cd UpdateOrchestrator && rename Reboot Reboot.backup && rename Reboot_Battery Reboot_Battery.backup && rename Reboot_AC Reboot_AC.backup && rename USO_UxBroker USO_UxBroker.backup && mkdir Reboot && mkdir Reboot_Battery && mkdir Reboot_AC && mkdir USO_UxBroker && copy NUL Reboot\empty_file && copy NUL Reboot_Battery\empty_file && copy NUL Reboot_AC\empty_file && copy NUL USO_UxBroker\empty_file