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

[slonopotamus]

Exit code: 0xbc2, restarting: Yes

Surprisingly, 0xbc2 == 3010.

[schwit61]

What are the meaning/significance of 0xbc2 and 3010?

[denelon]

3010 is the MSI return code for "ERROR_SUCCESS_REBOOT_REQUIRED"

https://learn.microsoft.com/en-us/windows/win32/msi/error-codes

[EgorEmeliyanov]

Yes, it's just an exit code that means "Soft reboot". This does not mean that the installer initiated a reboot -- interpreting this exit code is up to the calling system -- it can be a message box or simply an stdout notification that a reboot is recommended. Winget interprets this as "reboot asap, no prompts" -- this is very arbitrary.

The opposite of this code is 1641 -- that would mean that the installer has completed successfully and is calling InitiateSystemShutdown. In that case a reboot is justified as it's outside of winget's control.

[denelon]

@schwit61 thanks for the log.

The first line shows me the offending package is "Microsoft.VCRedist.2013.x64" version 12.0.40664.0 WinGet is passing "norestart" as one of the arguments.

This is coming from the manifest:

https://github.com/microsoft/winget-pkgs/blob/576773efca0e61229bb875913dc7f971c2d10c25/manifests/m/Microsoft/VCRedist/2013/x64/12.0.40664.0/Microsoft.VCRedist.2013.x64.installer.yaml#L16-L22

I also see the exit code followed by "Restarting computer..." at the end of the log.

In the "middle" of the log you can see where the "burn" "WixBundle" is doing some bootstrapping and installing a pair of MSI packages "internally".

The first line with "restart: Required" is:

[2460:5EF0][2023-01-22T08:57:38]i319: Applied execute package: vcRuntimeMinimum_x64, result: 0x0, restart: Required

The next line with "restart: Required" is

[5608:5FE4][2023-01-22T08:57:39]i372: Session end, registration key: SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall{042d26ef-3dbe-4c25-95d3-4c1b11b235a7}, resume: ARP, restart: Required,

Then on:

[2460:5EF0][2023-01-22T08:57:39]i399: Apply complete, result: 0x0, restart: Required, ba requested restart: No

As far as I can tell, WinGet is passing the argument to suppress reboot to the installer, but it does not appear to be honoring the request. WinGet is also treating the 3010 return code as a "success".

I did some digging and the issue may even be a bit more complex.

[eirinn1975]

I just experienced a reboot after an upgrade -all. The package triggering the reboot was MS Visual C++ Redistributable Package 2013

[chylex]

Uninstalling Dokany caused a reboot. I kind of expected it, but it's still a terrible user experience, especially if I wanted to uninstall multiple packages that each need to reboot.

[MisinformedDNA]

@denelon Have you guys reached out to Chocolately or AptGet (R.I.P.)? I've never experienced reboots with them.

[denelon]

We've found a couple of packages that don't honor the reboot suppression flag. We believe MSIs are handled correctly, but several .exe's still reboot even when you tell them not to, or the MSI calling into them doesn't pass the flag along. We're having to look into some deep edge cases still.

It seems the most common case is updating a dependency that is a running process that requires reboot to get properly referenced/loaded.

[xhoy]

Hi, is there been any progress in the last 10 months on this issue? We would love to silently deploy software, but this may not trigger any reboots....

[nascentt]

@denelon Have you guys reached out to Chocolately or AptGet (R.I.P.)? I've never experienced reboots with them.

The way Chocolatey does it is by spamming shutdown -a constantly whilst doing actions.

[nascentt]

Hi, is there been any progress in the last 10 months on this issue? We would love to silently deploy software, but this may not trigger any reboots....

We've been holding off deploying this for years now because of this issue. We're not about to switch over to an app management system that sometimes reboots machines. How this hasn't been a critical priority issue I'll never know.

[nascentt]

Is Winget abandonware?
No activity on this in half a year. No resolution in 4 1/2 years. Winget is unusable in this state.

[Masamune3210]

Amazingly enough, this is not, in fact, the only issue that exists for the entire project, and figuring out why the installers are misbehaving and how to work around it isn't exactly simple.

And no, spamming 'shutdown -a' will not work. All that does is abort any existing shutdown timer. It doesn't do anything if a timer isn't used or if something uses one of the dozen other ways that exist to cause a reboot.

[nascentt]

I was just stating what chocolatey does in response to denlon.

I'm sure there's many issues remaining in Winget, sadly this is the main one blocking it from being usable in any way.

[Masamune3210]

........many people use it all the time. I use it practically every day, to the point that I don't even bother going to sites to download things anymore, I just grab it through Uniget, which is just a GUI frontend for winget

[nascentt]

........many people use it all the time. I use it practically every day, to the point that I don't even bother going to sites to download things anymore, I just grab it through Uniget, which is just a GUI frontend for winget

Sure it's a great random reboot generator that also installs software. I use it at home too. Not really suitable for an enterprise environment though.

[Blacklands]

Does Winget have any real interest of dealing with this issue, as far as its whole design philosophy goes? It would appear to me that things like this issue are basically out of scope for it.

All it really does (for the most part) is download and run installers (or copy files and add a path to PATH for portable software), doesn't it? Which is not meant to downplay the work that goes into Winget - I just mean that Winget's design philosophy doesn't seem to be to actually control the actual software installation process. I know it calls itself a "Package Manager", but it's really more a "software fetcher", isn't it? It doesn't host any actual packages (just install manifests), it doesn't actually "package" anything, it doesn't maintain its own list of the software it has installed (it just reads from the Windows Registry, and if software doesn't write to that correctly then Winget is helpless - see for the example the still-ongoing issues with managing Discord through Winget). There's also the ongoing issue of dealing with unwanted shortcuts that software creates because it doesn't offer the right install flags to control that... and other issues of that kind. It seems to me that the Winget development team basically just treats all of these as "not our responsibility". Winget is not actually a Package Manager in the way that e.g. Chocolatey or the various Linux Package Managers are.

So I think even something like spamming shutdown -a is out of the scope for Winget. It doesn't want to care about what software installers are doing, it just wants to download and run them and throw its hands in the air about what happens beyond that. I'm not that happy with the state of things myself, when I started using Winget I was under the impression that this is an actual package manager - but I personally no longer believe that now. shrug

[slonopotamus]

Well, I do not fully agree.

I wrote an absolutely canonical MSI package that scheduled a reboot via standard MSI mechanisms. But the way winget was invoking MSI installation converted a scheduled reboot into an immediate reboot. Note that both MSI and winget technologies come from Microsoft, so I believe it is winget responsibility to make them work together is an adequate way (and this has happened, though it took several years: https://github.com/microsoft/winget-cli/pull/2499).

Current issue also mentions VCRedist triggering reboots. Who is responsible for fixing this? Microsoft-as-VCRedist-owner or Microsoft-as-winget-owner? In either case, it is Microsoft.