Error 1603 -- easy work-around and easy fix.
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?
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
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?
It looks like there is also an association with #152
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.
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.
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
We will be implementing #149 User vs. System Installation (non MSIX). That should help with installers that require elevation.
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.
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.
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.
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.
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
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]
Experienced the same issue while installing LibreOffice, and it's surprising to see the feature has not been added yet.
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.
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.
FYI: In my case, -i told me that a machine reboot was required.
1603 when installing SSMS with elevated permissions.
UPDATE: After a reboot, in installed fine.
@bobfrankston - Are you still experiencing this issue on the latest version of WinGet (1.7.10582) ?
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?
I fixed it by running Winget in a "Run as Administrator" terminal.
Same here. For all updates with winget.
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"
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.