Doesn't work from elevated command prompt

[orc4hrie]

Brief description of your issue

Steps to reproduce

Try to install an app. Fails. Try to install from elevated prompt. Fails.

Expected behavior

Install the app

Actual behavior

Fails

Environment

Windows Package Manager v1.0.11451
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.19042.985
Package: Microsoft.DesktopAppInstaller v1.11.11451.0

Any other software?

[denelon]

@orc4hrie which package are you trying to install?

Would you mind submitting a feedback report so we can see the logs?

[orc4hrie]

Anything; winget won't even run in an elevated prompt. From a non-elevated prompt any install or upgrade gets an access denied error, or silently fails. I'll go through the feedback hub.

PS C:\WINDOWS\system32> winget
Program 'winget.exe' failed to run: The file cannot be accessed by the systemAt line:1 char:1

• winget

At line:1 char:1

• winget

•   + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed
  

[KineticTheory]

I'm seeing this on corporate machine where my regular account doesn't have 'administrator' privilege. To do admin tasking, I start cmd.exe as an Administrator (using a separate username and password). In this cmd shell I see the following (my actual username is masked with XXX; rXXX is my user account that has admin privilege.):

C:\> where winget.exe
C:\Users\rXXX\AppData\Local\Microsoft\WindowsApps\winget.exe

C:\> dir C:\Users\rXXX\AppData\Local\Microsoft\WindowsApps\winget.exe
 Volume in drive C is Windows

 Directory of C:\Users\rXXX\AppData\Local\Microsoft\WindowsApps

05/31/2021  10:34 AM                 0 winget.exe
               1 File(s)              0 bytes
               0 Dir(s)  298,889,244,672 bytes free

C:\> C:\Users\rXXX\AppData\Local\Microsoft\WindowsApps\winget.exe
The system cannot execute the specified program.

It seems that winget.exe is a special file (zero size) that doesn't work in this environment.

If I run winget.exe from my normal account, it runs as expected but I must provide credentials for almost every install command. Since my rXXX account requires 2FA with a smart card and PIN, this is very tedious and I would prefer to run winget from the elevated command prompt.

[denelon]

@KineticTheory, the zero byte size file is fine. It's related to the App Execution Alias. I believe you will need to have the App Installer registered under the other administrator account for this scenario to work currently.

[KineticTheory]

@KineticTheory, the zero byte size file is fine. It's related to the App Execution Alias. I believe you will need to have the App Installer registered under the other administrator account for this scenario to work currently.

@denelon This is not my experience. I can logon to my machine as the admin-class user and winget works correctly from a command prompt. I'm assuming this means that the App is registered correctly for the admin-class user. However, winget does not work from an elevated command prompt (using the credentials that I just tested) when I am logged in as a normal (non-admin) user.

[JohnMcPMS]

I'm not sure how well the AEA (App Execution Alias) works when running from the context of a user that is not actually logged in. I don't know if that is the issue here, but this setup is certainly going to cause issues if you run installers that are user specific in that context. Not that you would normally need to do that, as the elevated privileges are usually only needed for system wide installs (although not always). But this would be an issue for the installer with any over the shoulder authorization.

[denelon]

@orc4hrie

We've published the v1.1 release candidate and updated our troubleshooting guide.

Can you confirm if this is still happening?

[orc4hrie]

Winget still fails to run from an elevated command prompt, but some recent update has made it less necessary to do so. It now properly prompts for admin rights as needed when from from a standard prompt.

[dbaileyut]

I believe I have a related use case / issue with MSIX:

Again, scenario is that I am logged in as "myUser" without admin rights. I run cmd.exe or powershell.exe using right-click "Run as administrator" and elevate as the different "adminUser". I get "The system cannot execute the specified program." or "Program 'winget.exe' failed to run: The file cannot be accessed by the system" depending on the shell.

1. Version: v1.1.12653
2. App execution aliases - enabled
3. (Get-Command).Source: "C:\Users\adminUser\AppData\Local\Microsoft\WindowsApps\winget.exe"; $env:Path has "C:\Users\adminUser\AppData\Local\Microsoft\WindowsApps"

If I log in directly as "adminUser", winget runs as expected whether elevated or not.

[denelon]

I also believe the root of the Issue here is related to how MSIX packages are provisioned for users.

This isn't something we're going to be able to change.

We've got work related to this:

• Develop Intune integration #215

It's going to require installing a separate package that we will be releasing to expose the COM interface to "in process" applications. Keep your eye on that Issue as we're actively working on it.