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?

[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: #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.