# Windows App Updates Failed: Check the Stage Before Retrying

An app has an update, but clicking Update never seems to finish. Check whether it is downloading, awaiting administrator approval, installing or verifying the installed version. Repeated clicks do not advance an installer waiting for your decision.

## Separate a slow download from a failed installation

Mole's update row identifies the stage. Downloads show a percentage when a total size is available, otherwise the downloaded amount. Changing numbers indicate progress. Downloads can be cancelled; after installation starts, that control does not kill the installer and leave a partial installation.

| Where it stops | The first check |
| --- | --- |
| No download progress or a server error | The download address, connection and vendor service; retain the full error |
| Requesting administrator access | The taskbar and Windows approval prompt |
| Installing with another window open | Whether the installer awaits app exit, confirmation or a restart |
| Finished but the version is unchanged | The app's About page, installation scope and whether it needs reopening |

A rejected download may mean the installer never ran. It does not establish a damaged installer or require uninstalling the working version first.

## Interpret an error in the installer's own context

Windows Installer results illustrate why different failures need different actions.

| MSI code | Meaning | Next step |
| --- | --- | --- |
| 1603 | A general installation failure | Read the log for that attempt; the code alone does not name the cause |
| 1618 | Another installation is running | Let that installation finish before starting another |
| 3010 | Success, with a restart required to complete it | Save work, follow the restart request, then verify the version |

These meanings come from Microsoft's [Windows Installer code table](https://learn.microsoft.com/en-us/windows/win32/msi/error-codes). They apply to MSI results, not every vendor's EXE installer. In particular, 3010 does not mean a failed download needs reinstalling.

## Locate logs without repeating the installation

This PowerShell query shows WinGet's version, environment and log directory without starting an app update:

```powershell
winget --info
```

Find the log for the failure time, then match the app name, package ID and timestamp. Separate a download response from an installer exit or a later version check. Logs can contain usernames and local paths; remove unwanted details before sharing them through support rather than posting an entire archive publicly.

Keep the time of the attempt, original app version, complete code and any approval or restart request together. Otherwise, a failure from yesterday's unrelated installation can look like the cause of today's problem. [WinGet's troubleshooting documentation](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting) explains this log lookup without requiring a forced reinstall.

<figure class="blog-diagram">
  <picture>
    <source media="(max-width: 900px)" srcset="/img/blog/windows-windows-app-update-failures-en-mobile.webp" type="image/webp" width="768" height="1500">
    <img src="/img/blog/windows-windows-app-update-failures-en.webp" width="1360" height="454" loading="lazy" alt="An update has distinct stages">
  </picture>
  <figcaption>Locate the affected stage. Approval is conditional, and version verification follows installation and any required restart.</figcaption>
</figure>

## Some updates remove an older version first

Installers such as Java 8 can require removing the old version. A machine-wide installation may need administrator access, so a normal-user update may not complete. Mole handles supported update cases and requests approval when needed. Not every failure is a permissions problem.

Installers have different exit codes and behavior. Microsoft's [WinGet troubleshooting guidance](https://learn.microsoft.com/en-us/windows/package-manager/winget/troubleshooting) describes logs and error investigation. The code and stage are more useful for support than the word failed alone.

## Verify that the new version is actually in use

An app may have user-level and machine-wide installations, or use a displayed version different from its package registration. Open this installation's About page, check that the installer finished, and complete requested restarts. Repeated installation just to empty the update list is not a reliable fix.

Mole leaves an unchanged-version outcome available for review. Self-updating apps retain their own channels; the [update guide](/windows/blog/update-windows-apps) explains the entries. Browsers that update while open usually use the newer version after their next restart.

## Include versions and the exact error in feedback

Record Windows, Mole and the affected app's versions. Describe how far downloading, approval or installation reached, and include the error and a screenshot through the support route in [Windows help](/windows/help). Remove anything you do not want to share from logs first.

Mole's own updater, other app updates and Windows Update are separate queues. Investigate system-update errors through Windows records rather than treating one Apps failure as a reason to reset the whole system.


Canonical: https://mole.fit/windows/blog/windows-app-update-failures