Use WinGet to identify, repair or update an installed app without guessing the package
List the installed package first, verify its exact ID, then use repair or upgrade only when the package supports that operation.
- Run winget list with the app name to identify the exact installed package ID/version.
- Check whether an upgrade is available before issuing an upgrade command.
- Use an exact --id and -e where practical to avoid changing the wrong package.
- Do not use --force or bulk upgrade as the first troubleshooting step.
What this problem usually means
WinGet can list installed applications and supports targeted upgrade, uninstall and—where the installer supports it—repair. Exact package identity matters because ambiguous names can match multiple sources/packages; previewing/listing first is safer than bulk or forced operations.
What is known, and what is not proven yet
Keep observation, evidence and conclusion separate before making a higher-impact change.
One installed app needs identification, repair or update.
WinGet list output: exact package ID, installed version, source and upgrade availability.
The selected application package and its registered installer behavior.
Whether the package advertises repair/update support and whether the targeted operation changes the symptom.
Run one exact-ID repair or upgrade operation, then retest.
Application publisher when its installer fails even though package identity/source are correct.
Work from the narrowest fix to the broader one.
Target one verified package
Medium riskWhy this belongs here: Exact package identity keeps a repair/update operation scoped to the intended application.
- Run winget list "App name" and note the exact Id.
- If repair is supported and the app is malfunctioning, use winget repair --id <ID> -e.
- If an update is available, use winget upgrade --id <ID> -e.
- Retest the original symptom before changing any other app.
When this guide stops being the right path
Do not use winget upgrade --all, --force or uninstall commands as generic Windows repair. Package behavior and installer support differ between applications.
If the problem is still not fixed
If WinGet reports installer/package failure, open its logs when appropriate and use the application publisher’s installation guidance. Store/MSIX deployment codes belong in the Store package branch.
Sources reviewed for this page
Primary technical guidance is preferred. A source supports the scope stated here; it does not imply that every possible cause is covered.