Discord does not install

[revanmj]

Brief description of your issue

When trying to install Discord via winget, installer throws an error about lack of permission to copy file. Doesn't matter if this is done via Windows Terminal launched as admin or not (in the latter case, error left in console is different and only second error from attached screenshot is displayed).

Steps to reproduce

1. Launch Windows Terminal as admin
2. Issue winget install Discord command

Expected behavior

Discord installs properly

Actual behavior

Installation fails

Environment

Windows Package Manager v0.1.41331
Windows: Windows.Desktop v10.0.19041.264
Package: Microsoft.DesktopAppInstaller v1.0.41331.0

[revanmj]

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

[JohnMcPMS]

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.

[revanmj]

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.

[aditya-giri]

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

[jefferai]

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?

[Bartmax]

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

[hacker1024]

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

[AmitKKhanchandani]

Same issue with Atlassian.Sourcetree

[hacker1024]

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

[beppler]

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

[megamorf]

@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?

[beppler]

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).

[electronic-dk]

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.

[intel352]

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.

[smabuk]

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

[icedream]

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.

[electronic-dk]

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.

[icedream]

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}

[icedream]

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

[denelon]

@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.

[sreadingMSFT]

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.

[JohnMcPMS]

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.

[jefer94]

Doing the same that @icedream i can install postman

[JiiPee74]

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.

[Masamune3210]

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?

[JiiPee74]

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

[icedream]

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.