Auditing a 23-package backlog from winget upgrade

On this machine, winget upgrade --include-unknown showed 23 pending upgrades on 2026-07-19.

The size of the list was less striking than the version jumps. Azure Developer CLI was waiting to move from 1.23.1400 to 1.29.100, and GitHub CLI from 2.83.2 to 2.97.0. Putting the numbers next to each other exposed how long I had postponed updates. It looked less like an app inventory than a history of things left unattended.

This was not something special to ARM64 Windows. On an ARM64 machine such as the Surface Pro 11th Edition, however, native packages, x64 packages, Store distribution, and MSIX can appear in the same list. Looking only at the winget table makes the result closer to an inventory than to a complete update-management view.

I expected a short check, but the output was useful as an operations note. It became an inventory of where I had left things behind, not just an update table.

Commands used for the inventory

I ran winget upgrade --include-unknown, winget list, and winget source list. The machine was a Surface Pro 11th Edition with a Snapdragon X 12-core X1E80100 @ 3.40GHz, 32GB of memory, and Windows 11 Pro 10.0.26200 ARM64. AC power was connected and the power plan remained the default Balanced.

winget upgrade --include-unknown
winget list
winget source list

upgrade took 4.98 seconds, list took 10.72 seconds, and sources took 0.49 seconds. I was not comparing speed; I was preserving the pending-upgrade breakdown and source state. The observed sources were msstore, winget, and winget-font. The pending-upgrade table used winget and msstore.

winget-font was still registered in this environment, with the explicit flag set to true. It did not directly add these 23 items, but keeping the source list makes later review easier and provides a baseline if source differences become suspect.

The pending-upgrade list

upgrade.stdout contained 23 pending upgrades. The package name, ID, current version, and available version were:

The jump from Azure Developer CLI 1.23.1400 to 1.29.100 stood out immediately. Microsoft Azure CLI also spanned 2.80.0 to 2.88.0, and Azure Functions Core Tools 4.6.0 to 4.12.1. The numbers show that I installed Azure tools around the same time and then left them behind. It also reflects my habit of postponing the tools I use most often.

The Unknown current version for Roblox Player is also important. It appeared because of --include-unknown; winget offered 0.726 without being able to read the installed version. It may be an upgrade candidate, but the size of the version difference cannot be compared. An Unknown row increases the count but cannot establish how old the installation is.

Small-looking differences become meaningful when listed together. Microsoft Visual C++ 2022 Redistributable (Arm64) goes from 14.51.36231.0 to 14.51.36247.0, which is not a large jump. The x64 and x86 redistributables go from 14.50.35719.0 to 14.51.36247.0. Even on an ARM64 machine, Arm64, x64, and x86 runtimes remain installed together.

The MSIX list mixes ARM64 and neutral packages

list.stdout contained many MSIX-format packages. Some names included _arm64__8wekyb3d8bbwe, such as WindowsWorkload.PSOnnxRuntime.1_0.3.245.0_arm64__8wekyb3d8bbwe and Microsoft.RawImageExtension_2.5.24.0_arm64__8wekyb3d8bbwe. This confirmed that ARM64-native apps and runtimes appear in this form.

The same list also contained _neutral__8wekyb3d8bbwe: Microsoft.PowerToys.SparseApp_0.96.1.0_neutral__8wekyb3d8bbwe, Microsoft.Winget.Source_2026.803.1208.47_neutral__8wekyb3d8bbwe, and Microsoft.LanguageExperiencePackja-JP_26100.174.273.0_neutral__8wekyb3d8bbwe are examples. Architecture-specific packages and neutral packages coexisted on this ARM64 machine.

Looking only at the winget upgrade table highlights names such as PowerToys (Preview) ARM64. Looking at winget list also exposes many smaller MSIX components such as WindowsWorkload, WinML, PSTokenizer, and Speech Pack. Windows on ARM is made up not only of the application itself but of these supporting packages as well.

I cut off the beginning

The failure was how I saved winget list. The reason is simple in hindsight.

The JSON list.stdout began with rRenameContextMenu_0.96.1.0_neutral__8wekyb3d8bbwe. That was not the beginning of the table; it was a substring cut from the middle of PowerToys PowerRenameContextMenu. The header and earlier packages were gone.

The cause was my implementation, which saved only the last 20,000 characters of standard output. I discarded the beginning of the long winget list myself. Truncating piped output casually prevents a later all-package count. Because it did not fail as an error, it took time to notice.

This was a design mistake. Next time I will redirect standard output to a file first and then read it, for example winget list > winget-list.txt. Keeping the raw output allows the required range to be selected later. If embedding it in JSON, a path to the complete file is safer.

upgrade.stdout was short enough to produce the table of 23 items. list.stdout began partway through, so I do not report the count of all installed apps or an ARM64-to-x64 ratio. The evidence would not support those numbers. This article is limited to the pending-upgrade inventory.

An operating practice that does not accumulate updates

I now prefer to use winget upgrade first as an inventory rather than as a command to upgrade everything immediately. When Azure Developer CLI, Azure CLI, Functions Core Tools, OpenJDK, Node.js, and Python Launcher are all pending on one day, the order matters. If upgrading all of them breaks something, the cause is hard to isolate.

Writing the list out made the length of the backlog visible. Azure Developer CLI 1.23.1400 to 1.29.100, GitHub CLI 2.83.2 to 2.97.0, and Copilot CLI v1.0.47 to v1.0.77 were likely to matter because they are everyday tools. The larger the version jump, the harder it is to tell whether configuration files, authentication, extensions, or PATH behavior changed.

From now on I plan to keep dated results from winget upgrade --include-unknown, and update development tools separately from runtime components. Microsoft Visual C++ Redistributable and GameInput may be installed as application dependencies, so they should not be touched with the same momentum as CLI tools.

Even after reviewing it on July 19, 2026, my largest lesson was about logging rather than the command. Accumulating updates makes failures harder to diagnose, and truncating logs removes the evidence needed for that diagnosis.