Fix: winget upgrade Keeps Showing Outdated Apps (2026)

winget upgrade shows Microsoft.Edge as outdated. You upgrade it. Re-run winget upgrade. Microsoft.Edge is still outdated. WTF? Here's the most common winget bug and 7 ways to fix it.

Why this happens

Three root causes, in order of frequency:

1. Version string comparison quirk — winget thinks 1.0 < 1.0.0.0 even when they're the same
2. Duplicate install — you have the app installed twice (e.g. per-user AND machine-wide)
3. Manifest lag — winget catalog has a newer manifest than what the publisher actually ships

Fix 1 — Verify it's actually outdated

First, confirm winget isn't lying:

winget show --id <ID>

This shows the latest version per the manifest. Then check what's actually installed:

winget list --id <ID>

If both versions are the same numeric string but winget still reports outdated → version comparison quirk (Fix 2). If versions genuinely differ → real upgrade is needed but stuck (Fix 3+).

Fix 2 — Use --force to clear comparison quirk

winget upgrade --id <ID> --force

--force skips version comparison and reinstalls the current manifest version. After this, the app should disappear from winget upgrade.

If it reappears after a reboot — you have a duplicate install (Fix 4).

Fix 3 — Run with verbose log

If --force doesn't help, find out why the upgrade isn't sticking:

winget upgrade --id <ID> --log "$env:TEMP\winget.log" --verbose

Open the log. Look for lines mentioning:

• Installer exit code — the actual install result
• Package version — what's being installed
• Already installed — version skew detection

If you see Installer exit code: 0 but the version doesn't change in subsequent winget list, the installer succeeded but Add/Remove Programs didn't update — see Fix 6.

Fix 4 — Find and remove duplicate installs

Apps installed twice are the #1 cause of "won't upgrade":

winget list --id <ID>

If you see TWO entries — one with Source: winget, one without — you have both a winget-tracked install and a manually-installed copy.

Name              Id              Version  Source
Microsoft Edge    Microsoft.Edge  138.0    winget
Microsoft Edge    {GUID}          136.0

Uninstall both:

winget uninstall --id Microsoft.Edge
winget uninstall --id "{GUID}"     # paste the GUID from list

Then reinstall fresh:

winget install --id Microsoft.Edge -e

winget upgrade should now leave it alone.

Fix 5 — Use --include-unknown if the app installed manually

If the app was installed via vendor website (not winget), winget knows it's there but doesn't manage it:

winget upgrade --id <ID> --include-unknown

This tells winget to try matching the manually-installed app to a manifest. Sometimes works, sometimes the apps installed differently enough that winget can't take over — in that case uninstall + reinstall via winget.

Fix 6 — Refresh Add/Remove Programs registry

Some installers update files but forget to update the registry version string. Add/Remove Programs (and winget) reads that string. Force-refresh:

1. Uninstall the app fully:

winget uninstall --id <ID> --silent

2. Reboot (forces registry compact)

3. Reinstall:

winget install --id <ID> -e

Now the registry version matches reality.

Fix 7 — Pin the package to silence the warning

If none of the above works and you don't care to upgrade right now:

winget pin add --id <ID>

Now winget upgrade --all won't try this package. See winget pin guide.

Remove the pin later:

winget pin remove --id <ID>

Specific patterns

"Microsoft.Edge" reappears every upgrade

Microsoft Edge updates via Windows Update independently of winget. winget often sees version mismatch because its manifest version lags behind Edge's auto-update version. Pin it:

winget pin add --id Microsoft.Edge

winget upgrade --all succeeds but the same apps appear again

Restart Terminal. winget caches list state per process; re-running in the same Terminal can show stale data.

App version is "Unknown" in winget list

Name           Id           Version   Source
Some App       Some.App     Unknown   winget

Means the registry uninstall string doesn't contain a parseable version. Fix:

winget uninstall --id Some.App
winget install --id Some.App -e

After clean install, the version should populate.

Visual Studio refuses to upgrade

Visual Studio uses its own installer engine and ignores winget's upgrade. Use the actual Visual Studio Installer instead:

"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\setup.exe" update

Or pin and let VS manage itself:

winget pin add --id Microsoft.VisualStudio.2022.Community

winget shows version 0.0.0.0 → 1.x.x.x

The installed app has a malformed version. winget will keep flagging this. Force-reinstall:

winget upgrade --id <ID> --force

If that doesn't change the displayed version, the publisher's installer isn't setting it correctly — pin the package.

Quick checklist

When winget upgrade is being weird:

1. Is the version actually different? (winget show vs winget list)
2. Are there duplicate installs? (winget list --id <ID> — multiple entries?)
3. Does --force fix it for one cycle?
4. Does pinning silence the noise?

90% of cases are duplicate installs or version-string mismatches. Both have clean fixes above.

Prevention

To avoid this in the future:

• Install everything through winget from day one — don't mix vendor-website installs
• Use -e (exact) when installing so you don't install variants
• Don't run installers manually for winget-managed apps; use winget upgrade
• Reboot occasionally — registry inconsistencies clear after restarts

What's next?

• How to update all Windows apps → — upgrade workflow
• All winget error codes explained → — full reference
• MSI exit codes decoded → — installer return codes
• How to use winget pin → — version locking