winget upgrade -r / --recurse / --all stopped working

[drujd]

Brief description of your issue

I have upgraded to v1.8.1911 and now the -r / --recurse / --all options do not work at all.

Steps to reproduce

Have some packages (one is enough) ready to ugprade. Run winget upgrade -r.

Expected behavior

Packages that have newer versions available should start upgrading.

Actual behavior

Example output:

Name        Id                       Version Available Source
-------------------------------------------------------------
UPnP Wizard XLDevelopment.UPnPWizard 3.3.0.1 3.4.0.3   winget
1 upgrades available.
1 package(s) have pins that prevent upgrade. Use the 'winget pin' command to view and edit pins. Using the --include-pinned argument may show more results.
9 package(s) have version numbers that cannot be determined. Use --include-unknown to see all results.

Nothing starts upgrading, just a list of packages ready to upgrade.

Environment

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

Windows: Windows.Desktop v10.0.22631.3880
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.23.1911.0

Winget Directories
-----------------------------------------------------------------------------------------------------------------------
Logs                               %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\Diag…
User Settings                      %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\sett…
Portable Links Directory (User)    %LOCALAPPDATA%\Microsoft\WinGet\Links
Portable Links Directory (Machine) C:\Program Files\WinGet\Links
Portable Package Root (User)       %LOCALAPPDATA%\Microsoft\WinGet\Packages
Portable Package Root              C:\Program Files\WinGet\Packages
Portable Package Root (x86)        C:\Program Files (x86)\WinGet\Packages
Installer Downloads                %USERPROFILE%\Downloads

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

Admin Setting                             State
--------------------------------------------------
LocalManifestFiles                        Disabled
BypassCertificatePinningForMicrosoftStore Disabled
InstallerHashOverride                     Disabled
LocalArchiveMalwareScanOverride           Disabled
ProxyCommandLineOptions                   Disabled
DefaultProxy                              Disabled

[github-actions]

Hi I'm an AI powered bot that finds similar issues based off the issue title.

Please view the issues below to see if they solve your problem, and if the issue describes your problem please consider closing this one and thumbs upping the other issue to help us prioritize it. Thank you!

Closed similar issues:

• winget upgrade --all fails to perform upgrade (#4250), similarity score: 0.81
• v1.7.10582 upgrade --all fails without any errors or output (#4219), similarity score: 0.77
• winget upgrade --all does not work anymore (#4261), similarity score: 0.76
• winget upgrade --all does nothing even with version Windows Package Manager v1.7.10582 (#4266), similarity score: 0.76

Note: You can give me feedback by thumbs upping or thumbs downing this comment.

[mdanish-kh]

Can you share what you get when you run winget upgrade --id XLDevelopment.UPnPWizard --verbose-logs --open-logs?

After the command finishes, it'll open up the WinGet logs directory, can you share the latest log file generated? (should be the first file if you sort by last modified time)

[drujd]

Failed when searching source: msstore
An unexpected error occurred while executing the command:
UTF-8 string character can never start with 10xxxxxx

Well, I guess the problem is in the specific package then as direct targeted upgrade does not work either. It sucks that I do not get ANY error at all when running -r, though.

Generated log:
WinGet-2024-07-11-10-59-00.955.log

[drujd]

But I guess you can close the issue, or maybe should I change it to something like "Errors hidden and ignored when running -r"?

[drujd]

winget upgrade XLDevelopment.UPnPWizard --verbose-logs --open-logs:
WinGet-2024-07-11-11-02-41.310.log

[drujd]

Also worth noting is that removing the package and installing it again will result in the newest version being installed.

So there definitely is a bug, just not in the --recurse option necessarily (beyond it hiding all errors)

[mdanish-kh]

@drujd I'm curious if the command succeeds for you if you run winget upgrade --all --source winget or winget upgrade XLDevelopment.UPnPWizard -s winget

If not, can you try running a source reset through winget source reset --force in an admin terminal and try again?

---

@Trenly - this seems related to:

• UTF-8 string character can never start with 10xxxxxx #4328
• And your PR in winget-pkgs Set GeoID in sandbox to prevent msstore source errors winget-pkgs#160554

Would you have any thoughts around this issue?

[Trenly]

winget upgrade XLDevelopment.UPnPWizard --verbose-logs --open-logs: WinGet-2024-07-11-11-02-41.310.log

I think the error in the logs here is pretty clear

2024-07-11 11:02:42.131 [CLI ] Installer [X86,exe,Machine,] not applicable: Installer scope does not match currently installed scope: Machine != User
2024-07-11 11:02:42.136 [CLI ] Terminating context: 0x8a15002b at C:\__w\1\s\external\pkg\src\AppInstallerCLICore\Workflows\UpdateFlow.cpp:be

This means that you have a user scoped install on your machine, but the manifest in winget-pkgs specifies a machine scoped installer.
https://github.com/microsoft/winget-pkgs/blob/master/manifests/x/XLDevelopment/UPnPWizard/3.4.0.3/XLDevelopment.UPnPWizard.installer.yaml

---

Well, I guess the problem is in the specific package then as direct targeted upgrade does not work either. It sucks that I do not get ANY error at all when running -r, though.

Generated log:
WinGet-2024-07-11-10-59-00.955.log

In this case ther error appears to be related specifically to the msstore. However, I don’t think this is the same issue as #4328 @mdanish-kh; It presents woth the same symptoms, but the endpoint is different and the region appears to be set. This leads me to believe two things -

1. There may be a bug with the msstore source on the msstore side for UTF-8 string character can never start with 10xxxxxx #4328 (and possibly this issue too), which is sending unexpected responses
2. This could be an encoding issue in the cli itself where it is (clearly) expecting only UTF-8 strings but the data received from msstore is in UTF-16 (unverified). If the response from msstore isn’t going through Utility::Normalize then that could be part of the issue. It appears to me that the body of the response is UTF-8 (at least when viewed in a browser or postman) meaning this may not be the case, but it is possible that a control character is wrongly included or some other encoding error is happening on the msstore side which can’t be resolved by the cli

2024-07-11 10:59:01.707 [REPO] Sending http GET request to: https://storeedgefd.dsx.mp.microsoft.com/v9.0/packageManifests/XLDevelopment.UPnPWizard?Market=CZ
2024-07-11 10:59:01.707 [REPO] Http GET request details:
GET / HTTP/1.1

Content-Type: application/json

User-Agent: winget-cli WindowsPackageManager/1.8.1911 DesktopAppInstaller/Microsoft.DesktopAppInstaller v1.23.1911.0

Version: 1.6.0




2024-07-11 10:59:01.753 [REPO] Response status: 500
2024-07-11 10:59:01.753 [REPO] Response details:
2024-07-11 10:59:01.753 [FAIL] C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\CompositeSource.cpp(1127)\WindowsPackageManager.dll!00007FFB1E2C09DA: (caller: 00007FFB1E1FFC69) LogHr(1) tid(3580) 8007023E {Application Error}

The exception %s (0x    Msg:[std::exception: UTF-8 string character can never start with 10xxxxxx] 

[Trenly]

I did some more digging. Based on the log files, it seems the deserialization of the Response Details is what fails, and that happens in the HttpClientHelper. On lines 462 to 463 of the attached log, it's possible to see the logging -that correlates to lines 174 and 176 of the HttpClientHelper

2024-07-11 10:59:01.753 [REPO] Response status: 500 // Corresponds to line 174
2024-07-11 10:59:01.753 [REPO] Response details: // Corresponds to line 176

winget-cli/src/AppInstallerCommonCore/HttpClientHelper.cpp

Lines 172 to 181 in 43425fe

	std::optional<web::json::value> HttpClientHelper::ValidateAndExtractResponse(const web::http::http_response& response) const
	{
	AICLI_LOG(Repo, Info, << "Response status: " << response.status_code());
	// Ensure that we wait for the content to be ready before we log it; otherwise it will be truncated.
	AICLI_LOG_LARGE_STRING(Repo, Verbose, << "Response details:",
	response.content_ready().then([&](const web::http::http_response&) { return utility::conversions::to_utf8string(response.to_string()); }).get());
	std::optional<web::json::value> result;
	switch (response.status_code())
	{

I wonder if a different method from the http_response library needs to be used instead of to_string - maybe something like extract_utf8string, although that may not include all the needed details. Since I'm not able to repro the issue on my end, and setting the GeoID to World doesn't work on my machine, and I don't have a way to easily put wingetdev into the sandbox, there isn't a good way for me to test any changes. I'll continue trying to get a repro on my machine, but until I can get a consistent repro, this may have to wait for someone more technical than me

[Trenly]

However, If you follow the code back, the UTF-8 string character can never start with 10xxxxxx error message is in cpprestsdk/asynccrt_utils.cpp/count_utf8_to_utf16 which is called by cpprestsdk/asunccrt_utils.cpp/utf8_to_utf16 which is called by cpprestsdk/asunccrt_utils.cpp/to_utf16string. So I'm not entirely sure why the failure would appear to be on the conversion to UTF8, when the error message doesn't appear to be in the code path for conversion to UTF8

Edit: It may be in the response.to_string(). Following that through _http_response::to_string() calls http_msg_base::to_string() which calls http_headers_body_to_string which calls convert_body_to_string_t which calls to_string_t, and if _UTF16_STRINGS is defined, that gets remapped

winget-cli/src/cpprestsdk/cpprestsdk/Release/src/utilities/asyncrt_utils.cpp

Lines 605 to 607 in 43425fe

	#ifdef _UTF16_STRINGS
	utility::string_t __cdecl conversions::to_string_t(std::string&& s) { return utf8_to_utf16(std::move(s)); }
	#endif

[drujd]

I have already upgraded and cannot replciate the issue.

The point remains that --recurse should not hide all errors and just skip problematic packages. It should print the same errors you see when upgrading a single package