MSI 1618: Another Installation Is Already in Progress – Clearing the Lock

Fix it now

1618 is ERROR_INSTALL_ALREADY_RUNNING: another installation is already in progress and yours was refused rather than queued. Microsoft documents the mechanism as the _MSIExecute mutex, held while an execute sequence runs, and the documented way to know whether the installer is busy is to ask the service – not to count msiexec processes or kill them.

sc query msiserver
tasklist /fi "imagename eq msiexec.exe"

1. Read the CONTROLS_ACCEPTED line from sc query msiserver. Microsoft’s documented test is that the Windows Installer service is considered to be running when it reports accepting shutdown; that is the check a well-behaved installer makes before it starts.
2. Give it time. Windows Update and large suites hold the mutex for many minutes, and a refusal is the installer being correct rather than broken.
3. Check the obvious holders: Windows Update, the Microsoft Store, and third-party updaters for browsers, readers and OEM management tools. Let them finish.
4. If a restart is pending, take it. Transactions frequently do not clear until the machine has restarted.
5. In deployment scripts, retry on 1618 after a delay rather than terminating anything.

One msiexec.exe in the process list is normal even when nothing is installing – the service instance lingers. Killing that one achieves nothing and can leave a half-applied transaction behind.

If your installation now starts, you are done. If 1618 persists with nothing visibly installing, the next section explains what actually holds the lock.

Why it happens

Windows Installer serialises installations with a machine-wide mutex called _MSIExecute. Microsoft documents when it is held: while the installer is processing the InstallExecuteSequence, AdminExecuteSequence or AdvtExecuteSequence tables – in other words, during the part of an installation that actually changes the machine. A second caller is refused immediately with 1618 rather than made to wait, and it is left to the caller to decide whether to try again.

There is a second, less obvious way to get 1618, and it explains cases where nothing else is installing. Microsoft states that the error is also returned while the current process is processing the InstallUISequence or AdminUISequence table. Two installations cannot run in the same process, so a bootstrapper that launches a package while its own user interface sequence is still running collides with itself.

Microsoft’s own advice is not to guess from the process list. Where returning 1618 is impractical, the documented approach is to retrieve the current status of the Windows Installer service before starting, using QueryServiceStatusEx, and to treat the service as running when the returned status reports that it accepts shutdown. From a command prompt the equivalent is sc query msiserver and the CONTROLS_ACCEPTED line – which is a far better signal than counting msiexec processes, because the service instance lingers after every transaction.

Full reference

The codes, and which are exit codes

The difference between 1502 and 1503 is one sentence and it is the sentence that matters. 1502 tells you the incomplete per-user installation has been noticed and your installation continues anyway. 1503 makes the same statement without that assurance. If you are reading a log and trying to work out whether the earlier user’s problem stopped you, that clause is the answer.

Handling 1618 in deployment

In unattended deployment 1618 is a timing collision, not a fault, and the correct response is to try again. Wrap the installation in a retry loop with a delay of a minute or two and a sensible attempt limit, and treat repeated refusals as a scheduling problem to solve rather than a package to force. Configuration tools that let you define retry behaviour on specific exit codes should carry 1618 in that list. Microsoft’s documented pre-check – query the installer service’s status before starting – is better still, because it avoids the collision instead of recovering from it.

What the Application log will and will not tell you

Microsoft’s published Windows Installer event list covers product-level outcomes rather than transaction boundaries: 1033 records an installation completing with a status, 1034 a removal, 1035 a configuration change, 1036 an update, and 11707 and 11708 the success and failure of an installation operation. There is no documented event for the start of a transaction, so if you are hunting for one you are relying on undocumented behaviour. Use the installer service’s own state for “is it busy now”, and the 103x events for “what happened, and when”.

When it will not clear at all

• Reboot before anything more drastic. A restart resolves pending transactions during startup and clears the mutex as a side effect.
• Check for a second signed-in session with a dialog waiting on it. query user finds it and this is a common cause on shared machines.
• Check whether a management agent is retrying a failed package every few minutes, which produces a machine that is almost never free.
• If a product really was interrupted mid-transaction, expect to repair or reinstall it once the lock clears, and check its files and registration rather than assuming it is intact.

Every code this article covers

Confirm the fix worked

1. Your installation starts rather than returning 1618.
2. sc query msiserver shows the service idle again a short time after the install finishes.
3. The Application log carries a 1033 or 11707 for your product with a success status.
4. A second, small package installs straight afterwards, which proves the lock is being released normally.
5. On a machine where you stopped the service, confirm whatever was in flight is intact rather than half-installed.

Questions people ask about this