Suppress reboot on default

[peterjc123]

Description of the new feature/enhancement

I tried to do winget install 7zip and then it automatically triggers a reboot on my PC. It's not a good user experience. I think you should suppress the reboot after installation unless explicitly specified.

Proposed technical implementation details (optional)

Either design an option --reboot and make it off by default or just never reboot after installation.

[Lebrack]

Are you sure? I intalled 7Zip with no reboot action. Even MSI/EXE classic (manual) installation of 7Zip, don´t triggers a reboot.

[peterjc123]

Oh, maybe I have an existing 7zip installation. But anyway, we should not trigger reboot automatically.

[madcampos]

If I reboot after a install will winget be able to return to that point and continue after the reboot?

[denelon]

@peterjc123 the current implementation of the client 0.1 doesn't support a forced reboot. If an installer does, it's outside of the winget.exe client. You may have encountered a bug. I haven't been able to reproduce this in my test VM.

[blogcraft]

It happened to me while installing Visual Studio Community and Microsoft Teams.

[WereCatf]

I just installed LibreOffice with Winget and it rebooted Windows, causing me to lose quite a bit of work! That is definitely NOT a good experience.

Yes, I understand that it's LibreOffice's installer doing that, but this really needs to be fixed one way or another -- the PC should not be rebooting all of a sudden, with zero warning or anything. I don't even care how it gets fixed, maybe Windows needs a way for Winget to be able to inhibit reboots or something, I have no idea, but it's just not reasonable to expect Winget - users to close all of their open work and (attempt to) save their things when installing something, just in case Windows reboots without any prompt at all.

[chrisgalvan]

I had this issue while installing Visual Studio in my new computer. It did reboot in the middle of installation. I use a script to setup all my dev tools/apps and everything was good and dandy until it rebooted, there was not way to resume or know what programs installed or not.

Not sure if scripting is the way to go here or if even is a supported scenario but would be great to handle the reboots so I can finish intalling then rebooting.

[mmuffins]

The same just happened to me when upgrading manictime.manictime to 4.6.19.0.

[abbfmst]

Same issue here: I installed Jabra.Direct and was surprised to have my machine rebooting immediately.

[Masamune3210]

Just had visual c++ redist automatically reboot after upgrade

[dylif]

This needs to be fixed. How can a user safely run package upgrades in the background without fear of losing their work?

[o-l-a-v]

VMWare Workstation, winget upgrade --id VMware.WorkstationPlayer does not work.

winget install --id VMware.WorkstationPlayer over existing version forced a reboot.

• Can be suppressed, see: https://silentinstallhq.com/vmware-player-silent-install-how-to-guide/

[JoshuaVandaele]

This just happened again when updating LibreOffice through winget..

Windows Installer requires a system restart. Product Name: LibreOffice 7.2.5.2. Product Version: 7.2.5.2. Product Language: 1033. Manufacturer: The Document Foundation. Type of System Restart: 1. Reason for Restart: 1.
The Windows Installer initiated a system restart to complete or continue the configuration of 'LibreOffice 7.2.5.2'.

This is rather problematic, as I was running winget upgrade --all and there were other packages to still download/install

[slonopotamus]

I want to add some info from https://github.com/microsoft/winget-pkgs/pull/54370:

For some reason, installing Stevedore causes a reboot. But Stevedore MSI is not forcing a reboot. It only schedules a reboot. If you install Stevedore MSI manually, you're presented with a "would you like to reboot" dialog. If you install Stevedore via Chocolatey package, it returns 3010 exit code and Chocolatey warns user that reboot is scheduled. So, I am not sure what and why transforms scheduled reboot into a forced reboot when Stevedore is installed using WinGet. But I believe this is something that users are unhappy about in https://github.com/microsoft/winget-cli/issues/229 and what needs to be fixed on WinGet side.

[denelon]

@slonopotamus, thanks for the additional context. It's possible that since we're doing a "silent" or "silent with progress" the reboot isn't scheduled, it's forced. There may be another switch we can pass or another way to call the install to delay the reboot.

[slonopotamus]

For the reference, here's how Chocolatey installs MSI packages:

2022-03-15 17:48:57,518 12832 [DEBUG] - Running Start-ChocolateyProcessAsAdmin -validExitCodes '0 3010 1641' -workingDirectory 'C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore\0.3.3' -statements '/i "C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore\0.3.3\stevedore-0.3.3-x86_64.msi" /qn /norestart /l*v "C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore.0.3.3.MsiInstall.log" ' -exeToRun 'C:\windows\System32\msiexec.exe' 
2022-03-15 17:48:57,534 12832 [DEBUG] - Test-ProcessAdminRights: returning True
2022-03-15 17:48:57,942 12832 [DEBUG] - Elevating permissions and running ["C:\windows\System32\msiexec.exe" /i "C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore\0.3.3\stevedore-0.3.3-x86_64.msi" /qn /norestart /l*v "C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore.0.3.3.MsiInstall.log" ]. This may take a while, depending on the statements.
2022-03-15 17:49:11,408 12832 [DEBUG] - Command ["C:\windows\System32\msiexec.exe" /i "C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore\0.3.3\stevedore-0.3.3-x86_64.msi" /qn /norestart /l*v "C:\Users\m.radchenko.admin\AppData\Local\Temp\chocolatey\stevedore.0.3.3.MsiInstall.log" ] exited with '3010'.
2022-03-15 17:49:11,415 12832 [DEBUG] - Finishing 'Start-ChocolateyProcessAsAdmin'
2022-03-15 17:49:11,799 12832 [INFO ] - stevedore has been installed.

So, you may see that there's /norestart flag.

[damirkasper]

please forgive the dumb question but how is "/norestart" not automatically enforced on every single MSI based package? this has been a thing for decades at this point and part of the reason MSIs are so easy and predictable to work with. why wouldn't that be the default switch/flag behavior?

to echo everyone here i ran an winget upgrade all earlier and i have the zoom outlook plugin which was one of the apps needing an update and outlook was open... forced reboot a few seconds later followed.

not to complicate things but it almost seems like a way around these issues is to give us a way to pass parameters to the install strings so we can just blanket add /norestart REBOOT=ReallySuppress etc... that a lot of common installers require to install without restarting if we're expecting the manifest creators to add /norestart to their MSI based manifest files.

again MSI is the most common and often used windows installer payload wrapper. why would you not build your new windows "next gen" app deployer tool to not account for the most common windows based installer format options? is everyone developing this product from a macbook? have you never had to exist on a corporate primarily based windows infrastructure? if i was developing a new cli based installer framework my first 2 feature requirements would be - silent and unattended installs, and no forced reboots.

i am amazed by what this product has managed to achieve so quickly and impressively, while ignoring certain very seemingly obvious use cases.

[denelon]

Not every package has a "suppress reboot" option. We've implemented defer registration as a default behavior for MSIX packages. We needed to add a key to the manifest schema to warn users about reboots, and other intrusive behaviors like restarting explorer.exe. Those are changes are rolling out with the 1.2 client now.

Some packages "insist" on rebooting to avoid being in a torn state (like Visual Studio). Several packages depend on runtimes and libraries that require a reboot to be updated. Dependency support is in progress.

With MSI packages, we would likely need to modify the output to indicate to users that the application has requested a reboot so they can be informed. We would also want settings and an argument to disable the default behavior to allow reboot to override the default behavior.

This work item is larger in scope than just adding the default suppression for MSI.

It is possible to specify which arguments one wants executed using "--override".

Note: "--override" would also override any other arguments in the manifest. We also have a feature on the backlog to add additional arguments rather than just override them.

[WereCatf]

Personally, I'm just happy that this is being worked on and not just getting swept under the rug. I've grown pretty wary of performing updates with winget because I just can't trust it not to suddenly decide to reboot my system and cause me to lose everything I've got open; it'll probably take me a good while to unlearn this wariness.

[slonopotamus]

Not every package has a "suppress reboot" option.

1. /norestart is a builtin msiexec option. It exists independently of package.
2. The fact that there exist non-MSI packages that do not allow to suppress reboot is not a good excuse to avoid fixing those that have such option
3. As was said earlier, MSI package has an option to schedule reboot. But current WinGet logic transforms that into a forced reboot, taking away an option to decide when to reboot from user.

[denelon]

Not every package has a "suppress reboot" option.

1. /norestart is a builtin msiexec option. It exists independently of package.

Yes, we are aware of the `/norestart' option. It wasn't identified as a top priority when building the preview release and hasn't been a top priority since then.

2. The fact that there exist non-MSI packages that do not allow to suppress reboot is not a good excuse to avoid fixing those that have such option

This Issue is the feature request to change the default behavior for "all" packages, not just MSI based packages. Using the term "fixing" implies that something is broken. We're honoring the default behavior for running MSI packages. We will be changing the default behavior to "suppress reboot" as the title of the work item states.

3. As was said earlier, MSI package has an option to schedule reboot. But current WinGet logic transforms that into a forced reboot, taking away an option to decide when to reboot from user.

The option isn't removed. Using "--override" gives control of any arguments/switches passed to the installer.

@damirkasper's comment motivated me to share the methodology we're using to prioritize work on the roadmap.

[EgorEmeliyanov]

I understand that this is being worked on, just wanted to note that the reproduce-ability of this is highly system-specific and depends on the middleware components you have installed (such as "vcredist") and the applications you have open while the installation is running. I encountered this while installing Microsoft's very own PowerToys -- its MSI exited with code 3010 and winget rushed to force-restart without any warning. I'm hoping to see this feature request implemented soon. Thank you for your work!

[mickn277]

A build script isn't possible with a reboot after some installs. Automating Windows builds was looking promising, but mid-script reboot, then failure. 🤬

[FWest98]

I just had a case where an automatic update of Office (in the background) scheduled a reboot, which I was not aware of; then I did an winget update of a completely unrelated package that does not require a reboot, and my PC still randomly rebooted...

Until there is way around this unpredictable behaviour built-in, is there some workaround? Would something like winget upgrade --override "/norestart" work?

Edit: unfortunately, no; since --override only works for a single package while the common usecase would of course be to upgrade all at the same time.

[Kissaki]

@FWest98 if the installer provides that flag then yes, that should work.

[gerardog]

For gerardog/gsudo project, I created an .msi installer using WIX. It so simple, it just copies an .EXE file to Program Files\xxx. Turns out that if you upgrade (interactively) to a new version while the app is running, it asks something like "Do you want to force close the app, or restart later?". But if you use 'msiexec /quiet' or ´/passive´, then the machine restarts suddenly.

So, the reason this issue was 'hard' to reproduce is because target files must be in use first.

msiexec provides /norestart and /promptrestart. I've added '/norestart' switch to gsudo (3ca689a) and it worked, plus the reboot required (3010) return code was handled perfectly by WinGet, with no other change except the manifest.

But, we shouldn't change every manifest... Winget should use this flag by default for .msi files.

I've submitted PR #2499 to add /norestart by default.

[craigktreasure]

I just hit this after installing Microsoft.DotNet.SDK.Preview. Totally unexpected.

[schwit61]

Winget fails in the first impressions and human factors departments. Many users will start with a 'winget upgrade --all' and get rebooted. Many of them will never use the app again. It's like getting bit by a dog when you first meet.

And blaming the app being installed won't fix the broken trust.

[denelon]

@schwit61 is there any chance you have the logs or know which application upgrade triggered a reboot? We've got fields in the manifest that may be able to help.

Unexpected reboots are beyond "just" disruptive. We're working on ways to identify applications that force reboot on upgrade. Several enhancements in the last couple of releases have been aimed at the winget upgrade --all scenario.

MSIX packages and MSI packages generally handle reboot suppression well. We're dealing most often with .exe-based installers that trigger a reboot directly, or they update a dependency without passing reboot suppression to their dependencies. It's very much trial and error trying to classify which packages exhibit this behavior.

[schwit61]

Here is the log WinGet-Microsoft.VCRedist.2013.x64.12.0.40664.0-2023-01-22-08-57-12.087.log