KEMBAR78
Windows 10 v1809 and Server 2019 support was lost after v1.7.3481-preview · Issue #5318 · microsoft/winget-cli · GitHub
Skip to content

Windows 10 v1809 and Server 2019 support was lost after v1.7.3481-preview #5318

@jantari

Description

@jantari

Brief description of your issue

A change in winget CLI introduced back between v1.7.3481-preview and v1.7.10514 (see diff here: v1.7.3481-preview...v1.7.10514) has broken it on Windows Build 10.0.17763.x, which is Windows 10 v1809 and Windows Server 2019.

The issue specifically is that when running an install command targeting a REST source - the package could be anything, doesn't matter:

winget install --id "Notepad++.Notepad++" --source internal-rest-source --no-upgrade --silent --scope machine --accept-source-agreements --disable-interactivity --verbose-logs

winget will quit prematurely with exit code -1073741819 (0xc0000005)

the verbose log file ends with (full log in my comment below):

...
[CLI ] Source agreements satisfied. Source: internal-rest-source
[REPO] Creating PredefinedInstalledSource with filter [Machine]
[REPO] Creating new SQLite Index with version [Latest] at ':memory:'
[REPO] Reading MSI UpgradeCodes
[REPO] Examining ARP entries for Machine | X64
< Some log lines "Adding", "Skipping" or "Did not find" a bunch of programs >
[REPO] Examining ARP entries for Machine | X86
< Some log lines "Adding", "Skipping" or "Did not find" a bunch of programs >
[REPO] Examining MSIX entries for Machine

No errors. Looking at the source code, the last visible log message comes from here:

AICLI_LOG(Repo, Verbose, << "Examining MSIX entries for " << ScopeToString(scope));
IIterable<Package> packages;
PackageManager packageManager;
if (scope == Manifest::ScopeEnum::Machine)
{
packages = packageManager.FindProvisionedPackages();
}

and right after writing the log message, the FindProvisionedPackages API is called which does not exist in Windows Build 17763 - the documentation says it was introduced in Build 19041 (which is Windows 10 v2004). The method not being there is also very easy to verify by attempting to call it in PowerShell:

jantari@server2019:C:\Windows\system32
└─ PS> [Windows.Management.Deployment.PackageManager,Windows.Management.Deployment,ContentType=WindowsRuntime]

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     False    PackageManager                           System.Runtime.InteropServices.WindowsRuntime.RuntimeClass


jantari@server2019:C:\Windows\system32
└─ PS> $pkgm = [Windows.Management.Deployment.PackageManager]::new()
jantari@server2019:C:\Windows\system32
└─ PS> $pkgm.FindProvisionedPackages()
Method invocation failed because [Windows.Management.Deployment.PackageManager] does not contain a method named 'FindProvisionedPackages'.
At line:1 char:1
+ $pkgm.FindProvisionedPackages()
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (:) [], RuntimeException
    + FullyQualifiedErrorId : MethodNotFound

jantari@server2019:C:\Windows\system32
└─ PS>

All this is further corroborated by the fact that the command succeeds, even with the latest winget v1.10.340, if the --scope machine parameter is omitted, thus skipping that API call code path. So I am pretty sure this call is the only reason for the crash.

This is a bug because:

  1. v1.7.10514 and even the very latest release of winget are advertised as compatible with Windows 10 1809:

This release represents a servicing fix Windows Package Manager 1.10 release build for Windows 10 (1809+), and Windows 11.

  1. Even though Windows Server 2019 was never officially supported, winget versions v1.7.3481-preview, v1.6.3482 and prior worked great on it and it is wingets goal to make sure the Windows Package Manager works on earlier versions of Windows - thus it would be great if compatibility would be fixed, Server 2019 still has almost 4 years of life left.

Steps to reproduce

  1. Get a Windows Build 17763 machine compatible with winget (Windows 10 v1809 or Windows Server 2019 Core with the AppCompatibility feature-on-demand added or Windows Server 2019 Desktop Experience)
  2. Set up any winget version 1.7.10514 or later, up to and including the latest - on Windows Server 2019 the msix install won't work, so if you're testing with Windows Server extract and use an unpackaged winget instance
  3. Set up a private REST source
  4. Add the REST source to winget
  5. Attempt to install a program from the REST source with the above command, including the --scope machine parameter

Expected behavior

winget should download and install the software.

Actual behavior

winget quits with exit code -1073741819 before completing the task.

Environment

WindowsPackageManager
MainCopyrightNotice

Windows: Windows.Server v10.0.17763.7009
SystemArchitecture

KeyDirectoriesHeader
----------------------------------------------------------------------------------------
Logs                 %TEMP%\WinGet\defaultState
UserSettings         %LOCALAPPDATA%\Microsoft\WinGet\Settings\defaultState\settings.json
PortableLinksUser    %LOCALAPPDATA%\Microsoft\WinGet\Links
PortableLinksMachine C:\Program Files\WinGet\Links
PortableRootUser     %LOCALAPPDATA%\Microsoft\WinGet\Packages
PortableRoot         C:\Program Files\WinGet\Packages
PortableRoot86       C:\Program Files (x86)\WinGet\Packages
InstallerDownloads   %USERPROFILE%\Downloads

Links
--------------------------------------------------------------------------------
PrivacyStatement         https://aka.ms/winget-privacy
LicenseAgreement         https://aka.ms/winget-license
ThirdPartSoftwareNotices https://aka.ms/winget-3rdPartyNotice
MainHomepage             https://aka.ms/winget
WindowsStoreTerms        https://www.microsoft.com/en-us/storedocs/terms-of-sale

AdminSettingHeader                        StateHeader
-------------------------------------------------------
LocalManifestFiles                        StateDisabled
BypassCertificatePinningForMicrosoftStore StateDisabled
InstallerHashOverride                     StateDisabled
LocalArchiveMalwareScanOverride           StateDisabled

Metadata

Metadata

Assignees

No one assigned

    Labels

    In-PRIssue related to a PRIssue-BugIt either shouldn't be doing this or needs an investigation.

    Type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions