Discord does not install about winget-cli HOT 36 CLOSED

+1, a bunch of apps all failed to install for me with this same error.

from winget-cli.

I reckon there've been no fixes from Microsoft because Git.Git also doesn't install.

from winget-cli.

I'm seeing the same behaviour in winget v1.0.11451 trying to install GitHub.GitHubDesktop (2.8.2) from an elevated prompt.
winget sees the result as successful, but the windowed app shows
Installation has failed - Unable to write to "C:\ProgramData\ ... IT policies etc.

Found GitHub Desktop [GitHub.GitHubDesktop]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licences to, third-party packages.
Downloading https://desktop.githubusercontent.com/releases/2.8.2-4423bb9d/GitHubDesktopSetup-x64.exe
██████████████████████████████ 110 MB / 110 MB
Successfully verified installer hash
Starting package install...
Successfully installed

from winget-cli.

Decided to follow @electronic-dk and run Get-AppxPackage -Name "Microsoft.DesktopAppInstaller" | Reset-AppxPackage and now it works for me as well.

from winget-cli.

Some info that may help investigate: I also hit the "Unable to write to C:\ProgramData\ - IT Policies may be restricting writing to this folder" issue.
For me the problem was that on that machine the command:
icacls "C:\Users\<user>\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState"
showed
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)
This was getting inherited to files in the \TempState\WinGet folder which is where the installers are downloaded to. CDing into the TempState folder and running:
icacls c:WinGet /setintegritylevel m
fixed the issue for me. (Possibly there's a better command to just break the inheritance rather than set to medium explicitly) On other machines I do not see that the TempState folder has this low mandatory label, so I'd speculate that it's either something about different initialization paths for the folder or possibly a version that some machines upgraded through but others skipped.

So yeah, wouldn't be surprised if repair and reset fixes it since those likely recreate the permissions on the appdata as well.

from winget-cli.

My issue got closed as a duplicate but I get "Access Denied" and it's definitely not installed. Seems like a lot of different behaviors are being lumped in as duplicates of this, is it all the same underlying cause?

from winget-cli.

Same issue with Atlassian.Sourcetree

from winget-cli.

Looks like @icedream found it was the directory, just as you did @sreadingMSFT . Most likely the issue has been this ACL the entire time, and we need to ensure that our temp directory does not inherit it.

Good to know that the repair and/or reset is fixing it while we work on an fix in the code to ensure that it doesn't happen.

from winget-cli.

Console output:

1. When run as admin:

C:\Users\revanmj>winget install Discord
Found Discord [Discord.Discord]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dl.discordapp.net/apps/win/0.0.306/DiscordSetup.exe
  ██████████████████████████████  59.7 MB / 59.7 MB
Successfully verified installer hash
Installing ...
Successfully installed!
An unexpected error occurred while executing the command:
remove: Access Denied: "C:\Users\revanmj\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\Discord.Discord.0.0.306.exe"

2. When run as normal user:

C:\Users\revanmj>winget install Discord
Found Discord [Discord.Discord]
This application is licensed to you by its owner.
Microsoft is not responsible for, nor does it grant any licenses to, third-party packages.
Downloading https://dl.discordapp.net/apps/win/0.0.306/DiscordSetup.exe
  ██████████████████████████████  59.7 MB / 59.7 MB
Successfully verified installer hash
Installing ...
Installer failed with exit code: 4294967295

from winget-cli.

The admin install is trying to remove the downloaded installer after a success. It should be installed in that case, but we need to fix the timing issue there.

As a normal user, that is a very unhelpful error code that they are returning, but I expect that they require Admin to install since they are writing to ProgramData.

from winget-cli.

There is no shortcut in Start Menu or entry in Add/Remove Apps panel, so winget wrongly assumes that install was successfull.

To add more context - first error from screenshot is displayed when status in console is still "Installing". Second one is displayed at the same time as the error in the console.

from winget-cli.

I get access denied as https://github.com/microsoft/winget-pkgs/issues/1367 but installation was successful

from winget-cli.

I get the same issue with Telegram.TelegramDesktop and Axosoft.GitKraken. Should this issue be renamed with a broader description?

from winget-cli.

I have the same problema with Git.
It works if my user is administrator and I run winget in an elevated prompt.
If my user is a normal account even if I run an elevated prompt (using an administrator account) it fails.

Git.Git.2.28.0.log

from winget-cli.

@beppler are you really sure that winget's parent process was started with elevated privileges? In your log it says:

 User privileges: None

Which implies that your process was only ran with the standard user access token. What's your UAC configuration?

from winget-cli.

Yes, I made the wrong test, If I my account is not an administrator and I start an elevated prompt (my UAC configuration is default), after type my credentials and try to run winget I'm getting the following message:

PS C:\Users\adm-beppler> winget
ResourceUnavailable: Program 'winget.exe' failed to run: The file cannot be accessed by the system.At line:1 char:1
+ winget
+ ~~~~~~.

If I try to install Git using the normal account the error is that in the log I sent.

If I switch user to the administrative account (MPS\adm-beppler), I can install it (after open an administrative prompt).

from winget-cli.

This looks like it can be addressed when we implement #149 User vs. System.

edit: Sadly I was wrong.
I'll hide this comment as irrelevant/no longer applicable.

from winget-cli.

This looks like the installer is launching a separate process to install. We don't yet track the installers in these kinds of situations. This appear to be related to the installers. I'll mark this issue as "Area-External" as we work through the right kind of a Feature that might resolve this issue.

from winget-cli.

But if winget install don't yet track the installers, we can't use winget install, also i need say that IT Policies is one feature of windows, he install Discord and appear one IT Policies error, I install Postman and appear the same error, we should look why IT Policies don't support winget to solved this issue

from winget-cli.

@jefer94 the Windows Package Manager tracks the packages installed by "packageIdentifier" from the community repository, or the source the package manifest originated from.

This issue is really about the mechanics of some specific installers. When the winget.exe client begins to install a package, it kicks off a child process and watches the return codes from that process to determine if the install completed, or threw an exception. In the case of Discord, it appears the installer (executed by the process winget.exe initiated) launches it's own child process, and the one we launched finishes with a successful result.

As the actual process that is running the install (executed by the installer process) isn't the one that was launched by winget.exe, We aren't receiving return codes from that other process to determine if there was a successful result or not.

The Windows Package Manager in process "A" launches process "B" to install Discord.
Discord's installer in process "B" launches process "C" to perform the install.
Process "B" exits with a success result.
The Windows Package Manager in process "A" receives the success result and reports success.
Process "C" encounters a failure, and no return code is provided to process "A".

from winget-cli.

Maybe the solution should be use packages instead of installers, we just need copy any package manager that it work, or specify one new installer standard that support winget. Also winget should support install package in other hard drive. But you think that exist a lot of package manager in the actually, and all work perfectly, exist one lot of behavior that it should be the behavior of winget, also you think if one user want to install 3 diferents packages and each installation fail, this user will not use winget, because it's not work

from winget-cli.

I was just able to install Discord. The shortcut also showed up in the Windows menu, and the program launched correctly.

Windows Package Manager v0.3.11102 Preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19042.928
Package: Microsoft.DesktopAppInstaller v1.11.11102.0

from winget-cli.

from winget-cli.

@jefer94 did you run this install in "user" mode or "administrator"?
I believe I receive a UAC prompt when I installed postman last in user mode.

If there are IT Policies restricting packages from installing to C:\ProgramData\ then the Postman installer would be denied access.

from winget-cli.

it show the same

from winget-cli.

I wasn't able to install discord via winget from either user or an elevated prompt. Unlike git, which at least worked from an elevated prompt. Although I'm getting a different error.

from winget-cli.

I get the IT policy error as well. Running winget via non-admin prompt, Discord errors with a reference to ProgramData path.
Winget correctly reports the install failed: Installer failed with exit code: 4294967295

EDIT: Install also fails when running via elevated (admin perms) prompt. Again programdata error, but winget in this case sees the install as successful.

from winget-cli.

I have found out something interesting: WinGet will let you know the URL from which it downloads the installer, so I decided to check whether the actual installer itself is at fault here, and it seems it is not, but I'm also not quite sure what's going on here.

For one, if you try to run the Discord installer WinGet downloads into %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet, that installer will refuse to work - as in will try to access C:\ProgramData\%USERNAME% - even if not executed from WinGet and executed with or without the same command-line parameters (WinGet runs it with /s).

If you download the EXE file through your browser instead or you decide to copy the EXE file WinGet downloaded to a new file, then both installer copies will work just fine. (EDIT: I double-checked with SHA256 hash checks and all hashes matched.)

Maybe this will help someone else to debug this? I am currently wandering through the source code and setting up for step-by-step debugging to find out what's going on, up until now I've found nothing useful other than this observation.

from winget-cli.

Looks like after doing repair and reset for the app installer package, discord was able to install from an unelevated prompt. I'll test it with more packages.

from winget-cli.

I wanted to reproduce the issue with step-by-step debugging but I was completely unable to do so. Builds done of the released version v1.0.11451 in Visual Studio 2019* run 100% fine, however the build that is in Azure Pipelines does have the same issue for me.

_{*weirdly, I had to make VS ignore some minor warnings from the SDK such as C6285 in order to make it work}

from winget-cli.

@icedream we've seen instances where the file path ends up being too long in some cases. I wouldn't be surprised if there were some other installer specific edge cases as well.

from winget-cli.

Doing the same that @icedream i can install postman

from winget-cli.

I have found out something interesting: WinGet will let you know the URL from which it downloads the installer, so I decided to check whether the actual installer itself is at fault here, and it seems it is not, but I'm also not quite sure what's going on here.

For one, if you try to run the Discord installer WinGet downloads into %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet, that installer will refuse to work - as in will try to access C:\ProgramData\%USERNAME% - even if not executed from WinGet and executed with or without the same command-line parameters (WinGet runs it with /s).

If you download the EXE file through your browser instead or you decide to copy the EXE file WinGet downloaded to a new file, then both installer copies will work just fine. (EDIT: I double-checked with SHA256 hash checks and all hashes matched.)

Maybe this will help someone else to debug this? I am currently wandering through the source code and setting up for step-by-step debugging to find out what's going on, up until now I've found nothing useful other than this observation.

I noticed that all installers in %localappdata%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet are in some sort of jail because if I try to move any of them to desktop I will get this popup

Maybe this will help to resolve all thouse access denied and IT policies things what some packages are facing.

from winget-cli.

That warning is caused by the files being tagged for a zone that is considered a warning by your Internet settings, could setting the zone be messing with the installers somehow? Maybe they are trying to extract or run something and end up getting redirected for some reason due to the security issue?

from winget-cli.

It's some security issue on TempState folder. I renamed it and created new and problem went away.

from winget-cli.

That warning is caused by the files being tagged for a zone that is considered a warning by your Internet settings, could setting the zone be messing with the installers somehow? Maybe they are trying to extract or run something and end up getting redirected for some reason due to the security issue?

This is irrelevant to the behavior of the installers and only determines whether Windows will explicitly ask you whether it should allow running the installer or not. The real reason has already been found with this comment.

from winget-cli.