MSI Installer Errors 1603, 1618 and 2502: What Each Code Actually Means

Most Windows errors are useless. MSI errors are an exception: the number genuinely narrows the cause, and the fixes for the common codes are unrelated to each other. Trying them in random order is why an install that needed a two-minute wait turns into an afternoon.

This applies to any .msi package — Microsoft Edge, Microsoft Teams, LibreOffice, Apache NetBeans and AWS Wickr all ship this way, and enterprise software overwhelmingly does, because MSI is the format Group Policy can deploy.

Work in code order.

1618 — another installation is already in progress

The most common code, and the easiest. Windows Installer allows exactly one transaction at a time. Something else has it.

What is usually holding it: Windows Update installing something in the background, the Microsoft Store updating an app, or another program's silent updater. None of these announce themselves.

The fix: wait two or three minutes and try again. That resolves most cases.

If it does not, open Task Manager and look for msiexec.exe. One or two instances are normal and belong to the service. If one has been running for a long time with no window attached to it, and you have confirmed Windows Update is idle, ending that process releases the lock — but check Windows Update first, because killing an update mid-transaction creates a worse problem than the one you started with.

2502 and 2503 — the installer cannot reach what it needs

These two travel together and both are permission failures. The installer service is running as a different security context than expected and cannot write where it needs to.

The fix, in order:

1. Run it elevated. Right-click the MSI and choose "Run as administrator". If that option is missing — and it often is for MSI files specifically — open an elevated command prompt and run msiexec /i "C:\path\to\package.msi".
2. Check the permissions on C:\Windows\Temp. These errors frequently trace to that folder having lost the permissions the installer service needs. It should be writable by SYSTEM and Administrators.
3. Confirm the Windows Installer service is running. In services.msc, "Windows Installer" should be set to Manual and be startable. If it is disabled, nothing will install.

Elevation resolves the large majority of 2502/2503 cases. If it does not, the temp folder permissions are the next place to look.

1603 — fatal error during installation

This is the code with no single meaning. It is Windows Installer's generic failure, and it can be any of:

• Insufficient permissions on a target folder
• The destination folder already exists, or is encrypted
• A custom action inside the package failed
• Not enough disk space
• A conflicting version of the same product already installed
• A dependency the package expected and did not find

Because the causes are unrelated, guessing wastes time. Get the log instead.

Reading the log

Run the installer from a command prompt with verbose logging turned on: msiexec /i package.msi /L*V install.log.

Open the resulting install.log and search for return value 3. Windows Installer records return value 1 for actions that succeeded and return value 3 for the one that failed. Everything after that line is rollback — the installer undoing its own work — and is not the problem.

The action name immediately before return value 3 tells you which subsystem gave up. A custom action name points at the package's own logic; a file-copy or registry action points at permissions or disk.

Search the log for error too, but the return value 3 marker is the reliable one.

The quick things worth trying before reading a log: run elevated, confirm there is real free disk space (installers need working room, not just the final footprint), and check whether an older version of the same product is already installed and should be removed first.

1719 — the Windows Installer service could not be accessed

The service itself is broken or disabled rather than busy.

The fix: open services.msc, find "Windows Installer", and confirm it can start. If it will not, sfc /scannow from an elevated prompt repairs system files, and that is the correct tool for a damaged service.

This code is rare on a healthy system and usually indicates something else has gone wrong more broadly.

1638 — another version of this product is already installed

Straightforward and specific: the same product code is registered at a different version.

The fix: uninstall the existing version through Settings, then install. If the existing version does not appear in the list or refuses to uninstall, that is a leftover registration and it needs removing before anything else will succeed.

Quick diagnosis

That last row is worth a moment. If Windows cannot open the package at all, the file is probably truncated or corrupt from the download rather than anything about your system. Check its SHA-256 against the published value before you try anything else — a failed install caused by a bad download looks identical to one caused by a broken system, and only one of them is fixed by re-downloading.

Things people try that rarely help

Registry cleaners. These are marketed as a fix for installer errors and almost never resolve one. The problem is a permission, a lock or a failed action, none of which a registry sweep addresses.

Disabling antivirus. Occasionally relevant if real-time scanning is locking a file mid-install, but far less often than forum advice suggests, and it leaves you unprotected while installing something. Try it late, not first, and re-enable it immediately.

Reinstalling Windows Installer. Not possible on modern Windows — it is a system component, not a redistributable. sfc /scannow is the supported equivalent.

Repeating the same install hoping for a different result. For 1618 this genuinely works, because the lock clears. For every other code it does not.

The short version

Read the number. It is doing real work.

1618: wait, retry. 2502/2503: run elevated. 1638: uninstall the old version. 1620: re-download and check the hash.

1603: get the verbose log with /L*V, find return value 3, and let the failing action name tell you which of half a dozen unrelated causes you actually have.

Every app named here resolves to a page in the FileCobra catalogue — the build fails if one does not. Versions, package sizes and system requirements are read from that catalogue rather than written by hand. Where our ingestion worker has fetched a release itself, it records a SHA-256 of the exact file we serve and publishes it on the app’s page. We do not run an antivirus lab: where a VirusTotal report exists we link it, and where none exists we say so rather than imply one.