Can't install anything, from any source

[fluffynuts]

Brief description of your issue

Everything I've tried to install via winget, even from different sources, has led to an error like this:

I've tried disabling antivirus (eset) altogether, no difference. If I go find the installer in my temp folder and double-click it, it runs just fine. I've tried running winget as a regular user and as administrator.

I have to assume I'm missing something fairly basic?

Steps to reproduce

winget install slcaktechnologies.slack or winget install discord.discord or winget install discord --source msstore

Expected behavior

I expected the installer to run

Actual behavior

Installer is blocked

Environment

Windows Package Manager (Preview) v1.3.692-preview
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.613
Package: Microsoft.DesktopAppInstaller v1.18.692.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

Links               
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

[jedieaston]

I'm guessing no, but are you in a corporate environment where your IT people might have messed with your security settings?

[fluffynuts]

I am on a domain, but our devops people tend not to enforce arbitrary constraints on the users. If they did, it's odd that I can launch the installer manually, surely? If you can suggest a way to verify the situation, I'm open to try (:

I thought it might have something to do with launching out of the temp folder, but I could be way off-base. I haven't seen a way to test this theory tho (ie, a way to tell winget to use another folder for temporary downloads).

[jedieaston]

Something to try would to be to reset your "internet zone settings", as sometimes they get flipped around to where you can't run exes from certain directories that are downloaded from the internet.

In the Start Menu, search for "Internet Options", then in that window, click security, then click "Reset all zones to default level". then click okay. If that doesn't work, I can tell you which settings in there you can manually flip (I don't have time at the moment, unfortunately).

[fluffynuts]

I've been through this stuff, so unless the "custom level" UI is lying to me, this is not the droid I'm seeking (mine is set to "confirm" for unknown sources). The UI could be lying tho. OTOH, this is a relatively new win11 machine - it's only been up about 2 weeks. I'd expect it to not be super-odd just yet :D

[rkeithhill]

Store app installation seems ... fickle to me. Try winget install slacktechnologies.slack -s winget. The default source is typically msstore. So that is where winget tries to install from if you don't specify a different source.

[ItzLevvie]

The default source is typically msstore

This will only happen if the company you work at configured the default source to be msstore via Group Policy.

So that is where winget tries to install from if you don't specify a different source.

WinGet's default source is still winget but ever since the msstore source rolled out to everyone you now need to be more specific on what package you want to install if you see the "Multiple packages found matching input criteria. Please refine the input." message.

Previously if you did winget install Ruby it'll install Ruby from the winget source but since there's a random app called "RubyGo" you will now need to do winget install RubyInstallerTeam.Ruby which will allow you to download Ruby from the winget source instead of a random app called "RubyGo" from the msstore source.

[rkeithhill]

WinGet's default source is still winget

Hmm, this is on my personal PC - no corporate GP:

The msstore source is first. 🤷‍♂️

[Masamune3210]

Pretty sure it's just alphabetical, could be wrong though

[rkeithhill]

Looking over the docs on the source command, I think you're right about the output being alphabetical. I see no mention of order/priority which makes winget a bit different than other pkg systems I've worked with.

@ItzLevvie I grok what you're saying now. Thanks for the clarification/correction.

[tyler274]

I'm not on any domain, and this is affecting me now. Even tried disabling everything I could find

[fluffynuts]

somehow, this is not affecting me any more; winget now "just works" (mostly). I'm not at all sure what changed.

[fluffynuts]

aaand... it's back, trying to winget upgrade --all and failing on the gvim installer that it got from github. I've reset all security zones, I've tried elevating, nothing. I'll have to hunt this installer down and run it manually, which I bet will work just fine

[fluffynuts]

yup, tracked it down within the %LOCALAPPDATA%\Temp\Winget folder, and the installer works just fine :|

[fluffynuts]

whilst I get that this issue (probably) isn't directly winget's fault, it's really annoying; something that would make it slightly less-so would be if winget printed out the full path to the installer it's trying to run, so it would be a little easier to track down.

I'm also not sure if perhaps changing the download location would help?

[fluffynuts]

Another thought I've had is perhaps it's related to install type? VIM has a .exe installer, so does Discord (that I had issues with). OTOH, so does the Humble Bundle app, and that installed fine 🤔

[fluffynuts]

I think that the location of the downloaded artifact may be the problem - changing the environment variable TMP to point at another temp location (C:\tmp), I could install things just fine. It would seem that perhaps winget should rather use a folder outside of the special %LOCALAPPDATA%\Temp location as it's being screened differently.

to re-iterate: setting the TMP environment variable, at the user level, was enough to bypass the installation issue.

[tyler274]

Same thing as noted with it working now, after a reboot at least.

[Karl-WE]

@fluffynuts for me it reads like a permission issue as if winget is trying to install in a different context.

Your Account is part of local Admin? Has the Admin group a Standard Name Are you using local Account or MS Account or Domain Account?

[fluffynuts]

It's not a permissions issue, since I could run the installer manually. This was so long ago and, iirc, on a different machine. I don't have the issue now, so either it was machine-specific or was "fixed by accident". It seemed like the automated process couldn't run the installer from a temp folder (where I could, from the same account and shell).

[designatedsuccessor]

Just adding to the pile: we are seeing this, too, now. This affects only *.exe installations; it does not affect other installation types.

I can manually install the *.exe files from these directories:

C:\Users<USERNAME>
C:\Users<USERNAME>\AppData
C:\Users<USERNAME>\AppData\Local
C:\Users<USERNAME>\AppData\Local\Temp\

But I cannot install from this directory:

C:\Users<USERNAME>\AppData\Local\Temp\WinGet

So it seems to be unique to the WinGet directory.

Here are some differences I see based on how I am logged in:

• If I am logged in as a standard user and then UAC-elevate to an administrator user once the installer *.exe requests me to elevate, the problem occurs.
• If I am logged in as an administrator user and then UAC-elevate once the installer *.exe requests me to elevate, the problem does not occur.

EDIT: I also noticed that it actually doesn't matter what *.exe file I put in the WinGet directory. I cannot install anything whatsoever from this directory. Example: let's say I browse a website and download an *.exe file from that website. If I copy that downloaded file to the WinGet directory, I cannot execute the file. So it's something unique about this directory.

EDIT 2: Just for testing, I gave the "Everyone" group all permissions to the WinGet folder. Here is what happened:

• If I use File Explorer to browse to the WinGet directory and run the files from there, the issue is temporarily resolved.
• If I go into the Microsoft Store to try to install an *.exe file from there, the issue returns, and the "Everyone" permissions are automatically/magically removed from the WinGet directory (which also makes the problem return when trying to manually run the *.exe files using File Explorer).

So it would seem that something related to the Microsoft Store or winget is constantly keeping its eye on the WinGet directory and constantly setting its ACL.

[denelon]

We've had several releases of WinGet since this issue was reported. Is this still happening?

[fluffynuts]

not for me - but I'm also on a new machine, so i've basically had a nuclear win?