Fix: winget 'Another Installation is Already in Progress'

You ran winget install and got "Another installation is already in progress" (exit code 1618). Here's why it happens, and 6 fixes from gentlest to nuclear.

Why this happens

Windows lets only one MSI installer run at a time, system-wide. The lock is held by msiexec.exe. If another process is already installing (Windows Update, an OEM updater like Lenovo Vantage, a previous winget that crashed without releasing the lock), winget can't proceed.

Error appears as:

Installer failed with exit code: 1618

or as part of a larger winget error block.

Fix 1 — Wait 2 minutes, retry

The first thing to do. Many "other installs" finish on their own. Wait 120 seconds, then:

winget install --id <ID>

If it works — done. The lock just needed to release.

Fix 2 — Check what's installing

Open Task Manager (Ctrl+Shift+Esc) and look for:

• msiexec.exe
• TiWorker.exe (Windows Update)
• TrustedInstaller.exe
• Any vendor updater (Lenovo, Dell, HP, MSI)

Or via PowerShell:

Get-Process | Where-Object { $_.Name -like "*msi*" -or $_.Name -like "*install*" }

If a Windows Update is mid-flight, wait for it to finish (could take 10-30 minutes). Don't kill TiWorker or TrustedInstaller — they're system processes.

Fix 3 — Kill stuck msiexec

If msiexec.exe is running but no real install is progressing (CPU 0%, no disk activity for 5+ minutes), it's hung:

Get-Process msiexec -ErrorAction SilentlyContinue | Stop-Process -Force

Then retry winget.

Fix 4 — Restart Windows Installer service

Sometimes the service itself gets stuck. Cycle it:

Stop-Service msiserver -Force
Start-Service msiserver

Or via services.msc:

1. Win + R → services.msc
2. Find Windows Installer
3. Right-click → Restart

Then retry winget.

Fix 5 — Clear the InProgress registry key

The persistent fix. When an install crashes, it can leave the "in progress" marker in the registry. Open Registry Editor as Administrator:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\InProgress

If this key exists with values:

• Right-click → Delete the entire InProgress key
• Reboot

After reboot, winget should work.

Alternatively from PowerShell (admin):

Remove-Item -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\InProgress" -Recurse -Force -ErrorAction SilentlyContinue

Fix 6 — Disable conflicting auto-updaters

If you keep hitting 1618 even after fixes 1-5, an auto-updater is holding the lock persistently. Common culprits:

• Windows Update — running on schedule
• OEM updaters (Lenovo Vantage, Dell Update, HP Support Assistant)
• GeForce Experience auto-update
• Adobe Updater
• Java Update Scheduler

Stop the worst offenders:

# Disable specific scheduled tasks (examples)
Disable-ScheduledTask -TaskName "GoogleUpdateTaskMachineCore" -TaskPath "\"
Disable-ScheduledTask -TaskName "AdobeAcrobatUpdate" -TaskPath "\"
Disable-ScheduledTask -TaskName "AdobeFlashPlayerUpdate" -TaskPath "\"

Or uninstall the OEM updaters entirely:

winget uninstall --id Lenovo.Vantage
winget uninstall --id Dell.Update

After cleaning up, MSI lock contention drops dramatically.

Fix 7 — Reboot (the universal solution)

If nothing else works:

shutdown /r /t 0

A reboot guaranteed releases all MSI locks. Re-run winget after Windows starts. ~95% of stuck-lock cases resolve here.

Why winget can't "just wait"

You might wonder why winget doesn't retry automatically. It does — for about 60 seconds. After that it errors out so you can intervene. Long waits would hide real problems.

You can tune this in settings if you want longer waits:

winget settings

Add:

{
  "network": {
    "downloader": "wininet",
    "doProgressTimeoutInSeconds": 300
  }
}

But the timeout isn't strictly for MSI lock contention — it's for download stalls.

Prevention

To minimise this happening:

1. Run winget when Windows Update isn't active — schedule installs outside Windows Update's typical 3 AM window
2. Disable OEM updaters — they fight winget for the MSI lock
3. Don't run multiple winget instances in parallel — winget itself queues commands but parallel calls confuse the picture
4. Reboot weekly — sounds silly but it clears all the cruft

Edge case: 1618 during winget upgrade --all

If you're updating 20 apps and one hits 1618 mid-way, the rest of the queue continues. winget reports failures at the end.

Re-run just for the failed packages:

winget upgrade --id <ID>

after waiting a minute.

What's next?

• All winget error codes explained → — full reference
• Installer hash does not match → — sibling fix
• Access denied 0x80070005 → — another common error
• MSI exit codes decoded → — installer return codes