0x80070652 and 0x80240016: another installation is already in progress

Fix it now

0x80070652 is ERROR_INSTALL_ALREADY_RUNNING, decimal 1618: another installation is already in progress and has to finish first. 0x80240016 is WU_E_INSTALL_NOT_ALLOWED, which covers both another install in progress and a system pending a mandatory restart. Neither points at a damaged update; both are locks.

net stop wuauserv
net stop bits
net start bits
net start wuauserv

1. Restart first, properly. Choose Restart rather than shutting down and powering on, because with fast startup enabled those are not the same operation. A restart is the mechanism by which a staged servicing transaction is committed and the pending state cleared.
2. If it returns, open Task Manager’s Details tab and look for msiexec.exe, TiWorker.exe or a vendor setup process that has been running a long time. Let it finish rather than ending it.
3. Install any servicing stack update on its own and restart before the cumulative update. An update marked exclusive cannot be installed alongside others.
4. Retry the installation.

Killing msiexec mid-transaction can leave the product it was installing half-configured. If you have to, restart afterwards and repair that product before judging whether the update problem is solved.

If the update installs after a clean restart, you are done. If the machine keeps reverting changes at boot, the next section explains what is holding the lock and how to clear it safely.

Why it happens

Windows Installer allows one installation transaction at a time for the whole machine. That is deliberate: two installers rewriting shared components simultaneously would produce a mess nobody could unpick. A second installer arriving while the first holds the lock is told the machine is busy, which is what 0x80070652 says in its published wording: another installation is already in progress, complete that installation before proceeding. The other installer may be visible, or it may be software updating itself quietly in the background.

Servicing has a separate transaction of its own. Once an update has been staged, the remaining work happens during the next restart, and until that restart completes the component store is in a pending state. 0x80240016 covers both halves of that: the operation tried to install while another installation was in progress, or the system was pending a mandatory restart. Some updates are additionally marked exclusive, and 0x80240019 is the code for exactly that, an exclusive update that cannot be installed with other updates at the same time.

This is why the restart is not a lazy first step. It is the mechanism by which a staged transaction is committed and the pending state cleared. Skipping it in favour of registry keys and service restarts usually means doing the restart later anyway, with more disruption and less certainty about what changed.

The remaining two codes describe the update agent’s own state. 0x8024001B is WU_E_SELFUPDATE_IN_PROGRESS: the operation could not be performed because the Windows Update Agent is self-updating. That clears on its own and needs patience rather than intervention. 0x80070308 is ERROR_REQUEST_OUT_OF_SEQUENCE, decimal 776: the client of a component requested an operation which is not valid given the state of the component instance. It is a state error, not a corruption error.

Full reference

Two different locks, one confusing message

Where the pending flags live

Read those locations, do not edit them. Deleting pending flags or the transaction file by hand does not complete the work they represent; it hides it, and the next update fails in a way that is much harder to diagnose.

Reverting pending actions, and when it is allowed

/RevertPendingActions reverts all pending actions from previous servicing operations, on the theory that those actions are what stopped the machine booting. Microsoft is explicit about the scope: it is not supported on a running operating system, nor on a Windows PE or Windows RE image. The supported use is an offline Windows image that did not boot, addressed with /Image: from a recovery environment started from installation media.

rem only for a machine that will not boot, from recovery media
DISM /Image:C:\ /Cleanup-Image /RevertPendingActions

rem for a machine that boots but keeps reverting changes
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

Reverting pending actions rolls back partly applied servicing work and can leave the machine in an unexpected state. Take a full backup or a snapshot first.

Telling a busy machine from a stuck one

• Watch disk and CPU in Task Manager rather than the clock. A large update or a database-backed application can be genuinely busy for a long time with very little on screen.
• Sustained zero across both, for a long stretch, is the signal that something has hung. A slow percentage is not.
• TiWorker.exe is the servicing worker. Seeing it consume CPU during an update is normal and not a reason to end it.
• Check whether another session has an installer open. On a shared or remote-desktop machine the lock holder is frequently somebody else’s setup wizard.
• If the same update fails repeatedly with 0x80070308, treat the state as the problem rather than the package: repair the store and clear the pending work before retrying.

Why this comes back every month

Usually because the machine is never restarted cleanly, so each month’s update stacks on the last one’s pending state. A scheduled restart after patching solves it more reliably than any command in this article. On servers, that means agreeing a restart window rather than deferring indefinitely; on desktops, it means letting the machine take the restart it keeps asking for. Fast startup complicates it further, because a shutdown followed by a power-on does not commit a staged servicing transaction the way a restart does.

Every code this article covers

Confirm the fix worked

1. Confirm no pending restart flags remain in the locations listed above.
2. Install the update that was failing and confirm it completes.
3. Restart and confirm the machine comes back without a configuration or rollback screen.
4. Check Update history and confirm the entry reads as installed.
5. Install a second update to be sure you cleared the lock rather than got lucky with one package.

Questions people ask about this