Closed drujd closed 1 month ago
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!
upgrade --all
fails without any errors or output (#4219), similarity score: 0.77Note: You can give me feedback by thumbs upping or thumbs downing this comment.
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)
[comment]: <[Policy] Issue-Bug> [comment]: <[Policy] Command-Upgrade>
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
But I guess you can close the issue, or maybe should I change it to something like "Errors hidden and ignored when running -r"?
winget upgrade XLDevelopment.UPnPWizard --verbose-logs --open-logs
:
WinGet-2024-07-11-11-02-41.310.log
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)
@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?
[comment]: <[Policy] msstore>
@Trenly - this seems related to:
Would you have any thoughts around this issue?
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 #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]
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
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
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
https://github.com/microsoft/winget-cli/blob/43425fe97d237e03026fca4530dbc422ab445595/src/cpprestsdk/cpprestsdk/Release/src/utilities/asyncrt_utils.cpp#L605-L607
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
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:
Nothing starts upgrading, just a list of packages ready to upgrade.
Environment