winget-cli icon indicating copy to clipboard operation
winget-cli copied to clipboard

Error 1603 -- easy work-around and easy fix.

Open BobFrankston opened this issue 5 years ago • 22 comments

Brief description of your issue

Steps to reproduce

I tried installing Adobe.brackets.

It failed with 1603

Run in admin shell and it works.

Before I get into it there are two problems with easy fixes

  • Instead of error 1603 give an actionable message. This is such a fundamental point that I shouldn't have to say it for the umpteenth time.

  • The fix was to run it with privilege. Tell me that in the error message and, better, offer, to do it automatically.

Expected behavior

Install brackets

Actual behavior

Error 1603

Environment

Powershell

[winget --info]
Windows Package Manager version V0.1.41331 Preview
Windows: Windows.Desktop version 1609
Package: Microsoft.DesktopAppInstaller version

Any other software?

BobFrankston avatar May 20 '20 18:05 BobFrankston

Definitely agree. Brackets was the first thing on the list I decided to try out and had the exact same experience. For some reason I expected this to install applications into user-space.

While I can appreciate the idea and the direction things are headed with this, it is extremely off-putting that the very first attempt to install something by following the listed instructions yields a useless generic 'stop you in your tracks' error.

Thanks, -MH

MostHated avatar May 20 '20 22:05 MostHated

This error code appears to be coming from the installer and not winget.exe. We have an Issue to deal with non-zero exit codes on success in the backlog. We also have #152 that may cover this scenario. Is this a duplicate, or something else?

denelon avatar May 28 '20 17:05 denelon

It looks like there is also an association with #152

denelon avatar May 30 '20 00:05 denelon

I just had an error 1603 come up when trying to install an application that already existed. Removing the application fixed the error without a need for elevated privileges.

panasenco avatar May 31 '20 05:05 panasenco

Got error 1603 while trying to install Powershell 7

PS C:\Users\risharan> winget install --name PowerShell --exact
Found PowerShell [Microsoft.PowerShell]
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://github.com/PowerShell/PowerShell/releases/download/v7.0.3/PowerShell-7.0.3-win-x64.msi
  ██████████████████████████████  87.0 MB / 87.0 MB
Successfully verified installer hash
Starting package install...
Installer failed with exit code: 1603
Installer log is available at: C:\Users\risharan\AppData\Local\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\TempState\WinGet\Microsoft.PowerShell.7.0.3.log

note: On trying again with a powershell elevated to admin, i still got the same error.

rishavs avatar Nov 01 '20 14:11 rishavs

It appears there are a few reasons MSI installers return 1603. https://docs.microsoft.com/en-us/troubleshoot/windows-server/application-management/msi-installation-error-1603

denelon avatar Jan 07 '21 00:01 denelon

We will be implementing #149 User vs. System Installation (non MSIX). That should help with installers that require elevation.

denelon avatar Jan 07 '21 00:01 denelon

Cause You may receive this error message if any one of the following conditions is true:

Windows Installer is attempting to install an app that is already installed on your PC. The folder that you are trying to install the Windows Installer package to is encrypted. The drive that contains the folder that you are trying to install the Windows Installer package to is accessed as a substitute drive. The SYSTEM account does not have Full Control permissions on the folder that you are trying to install the Windows Installer package to. You notice the error message because the Windows Installer service uses the SYSTEM account to install software.

denelon avatar Apr 20 '21 21:04 denelon

This error message is coming from the MSI installer, and not the Windows Package Manager. I'll convert this issue into a Feature so we can add a better error explanations when we get error 1603 from MSI installers.

denelon avatar Apr 20 '21 21:04 denelon

I don't know if it helps, but I am experiencing the same issue with LibreOffice. If I download and install it manually, it works perfectly fine.

ln-12 avatar May 29 '21 12:05 ln-12

For TrackerSoftware.PDF-XChangeEditor, I got the exit code: 1603 when I did not notice that the program has been installed with its standalone installer. Removing the manually installed version got the winget install TrackerSoftware.PDF-XChangeEditor command to go through.

llinfeng avatar Jul 10 '21 00:07 llinfeng

According to the documentation

When running winget without administrator privileges, some applications may require elevation to install. When the installer runs, Windows will prompt you to elevate. If you choose not to elevate, the application will fail to install.

but it doesn't work now.

For install the application in the current cmd session you can use interactive mode (option -i) or third-party sudo command

$ winget install -i LibreOffice
$ sudo winget install LibreOffice

ftoh avatar Aug 24 '21 08:08 ftoh

Running PowerShell (Admin) and using -i flag solved my problem

winget install -i <name>

I was facing issues with LibreOffice and VirtualBox Installer failed with exit code: 1603 [Running PowerShell (Admin) solved] Then, Installer failed with exit code: 3010 [Running in -i solved]

sabiviji avatar Sep 01 '21 07:09 sabiviji

Experienced the same issue while installing LibreOffice, and it's surprising to see the feature has not been added yet.

abuturabofficial avatar Oct 28 '21 04:10 abuturabofficial

This issue is complex, as there can be many causes of error 1603. I was receiving this in an automation when installing Adobe.Acrobat.Reader.64-bit. I was auto-installing each available version into a subdirectory named after the ID of the application. I was using "--override" to specify the install directory and getting 1603s. All permissions on path were wide open. /msi /qn INSTALLDIR=C:\SamplePath\Adobe.Acrobat.Reader.64-bit\22.001.20142 /norestart EULA_ACCEPT=YES I pre-created the Adobe.Acrobat.Reader.64-bit root directory and the errors went away. Feels like could be a bug within the Adobe installer when accepting an override path via winget, failing to create the path before the last segment. If using override, try pre-creating the root dir path.

Swamination avatar Jul 11 '22 07:07 Swamination

https://github.com/microsoft/winget-cli/issues/248#issuecomment-1180043647

@Swamination, have you reported the problem to Adobe? Some confirmation from them would be beneficial. I doubt that anybody but you shall bother, if able to, reproduce that problem.

RokeJulianLockhart avatar Jul 11 '22 21:07 RokeJulianLockhart

FYI: In my case, -i told me that a machine reboot was required.

sfiruch avatar Mar 23 '23 13:03 sfiruch

1603 when installing SSMS with elevated permissions.

UPDATE: After a reboot, in installed fine.

MisinformedDNA avatar Sep 15 '23 16:09 MisinformedDNA

@bobfrankston - Are you still experiencing this issue on the latest version of WinGet (1.7.10582) ?

Trenly avatar Mar 06 '24 04:03 Trenly

It's been so long that I forgot what adobe.brackets is but it does seem to install. But figured I'd give it a try to just to hukmor you since, obviously, the problem has been fixed ... or has it?

image image

BobFrankston avatar Mar 06 '24 15:03 BobFrankston

I fixed it by running Winget in a "Run as Administrator" terminal.

SalahAdDin avatar Apr 10 '25 04:04 SalahAdDin

Same here. For all updates with winget.

BananaAcid avatar May 25 '25 01:05 BananaAcid

Seems like 1603 is not a universal "run as admin" return code. For another software it was "even though it has no open visible window, it is running and cannot be during the update"

JustMyGithub avatar Jun 24 '25 03:06 JustMyGithub

In my case (updating Powershell), running the installer manually revealed that it tried uninstalling the previous version, but couldn't find the previous MSI to do so.

The new installer expected the old version's installer to be located at %TMP%\WinGet\Microsoft.PowerShell.7.5.2.0\PowerShell-7.5.2-win-x64.msi, which it wouldn't be for anyone that has removed their TEMPORARY files at any point.

So effectively, either Winget has to run an installer with some flag indicating that it should also include files to remove the application in the future (like creating an uninstaller as some software does), if such a flag even exists. Or installers in general shouldn't rely on needing to "safely" remove the previous version, if their installer doesn't exist any more.

For reference, Windows will show a message box with a file input field saying something like "The feature you are trying to use is on a network source that is unavailable," and asks you to point it to the old MSI. It is possible to go to the registry keys at Computer\HKEY_CLASSES_ROOT\Installer\Products and searching for that MSI, and then deleting the entire key, to trick the new MSI into thinking the old version is not installed any more. (So it stops trying to find the old MSI that doesn't exist any more.)

Another solution is to download the MSI of the old version yourself, and manually run the new MSI and point it to the path of the old one when it complains about the "source that is unavailable".

Of course, it is still not guaranteed that all the instances of the 1603 error above are caused by this problem.

ThenTech avatar Sep 13 '25 22:09 ThenTech