Skip to content

Est. 2011·Microsoft Partner 7033487·Delivery under 3 min·Support 7 days a week

Your vault is empty.

Free Fix 1603

MSI Error 1603: Fatal Error During Installation and How to Find the Cause

11 min read Updated October 5, 2026 Installers, Runtimes & App Deployment

Fix it now

1603 is ERROR_INSTALL_FAILURE, “A fatal error occurred during installation”. It carries no information about which action failed, so the log is not an advanced technique here – it is the only technique. Microsoft also publishes four specific conditions that produce it, and three of them are about the destination folder rather than the package.

Run this in an elevated Command Prompt, then read the log it writes

msiexec /i "C:\temp\app.msi" /l*v "C:\temp\install.log"
  1. Check whether the product is already installed. Microsoft lists that as the first cause of 1603; if it is there, uninstall it and install again rather than installing over it.
  2. Check the destination. Microsoft names an encrypted target folder, and a target on a drive reached through a substituted drive letter, as causes. Install somewhere plain and see whether the failure follows.
  3. Confirm SYSTEM has Full Control of the destination folder, applying to this folder, subfolders and files. The installer service does the privileged work as SYSTEM, so a folder the user can write and SYSTEM cannot fails here.
  4. Only then read the log. Work upward from the end for the last action that ran before the engine started unwinding; the twenty lines above it name the action and usually carry the underlying Windows error.

Do not skip the log because the four documented causes did not apply. The engine knows exactly which action failed and writes it down; the exit code simply has no room to say so.

If the install completes and the application starts, you are done. If not, the next section explains what the engine was doing and how to place the fault from the log.

Why it happens

An MSI installation is a sequence of actions: create folders, copy files, write registry values, register components, run whatever custom code the vendor added. The installer executes that sequence and each action reports back. The moment any action reports a fatal result, the engine stops, unwinds everything it has already done, and hands the caller 1603. That design is why the code is useless on its own and why the log is essential.

Microsoft publishes four conditions for this error, and they are worth checking before anything else because they are cheap. The product is already installed. The folder you are installing to is encrypted. The drive holding that folder is reached as a substituted drive. Or the SYSTEM account does not have Full Control of that folder – and Microsoft is explicit about why that matters: the Windows Installer service uses the SYSTEM account to install software, so permissions that look fine to the person double-clicking the package are not the permissions that count.

The companion numbers are different kinds of thing and it helps to keep them apart. 1627 is ERROR_FUNCTION_FAILED, “The function failed during execution” – an exit code, usually seen when a custom action fails. 1708 is “Installation operation failed”, which is an internal message rather than a process exit code. 2732 is “Directory Manager not initialized”, an internal error raised when an action calls into the directory manager before it exists, which is a packaging fault rather than a machine fault. And Event ID 11708 in the Application log is 1708 again: Microsoft documents that general errors from the Error table are logged with a message ID equal to the error number plus 10,000.

The product is already installed

You have this one if The failure comes early, and the application – or an older build of it – is present in Settings under Apps, Installed apps.

  1. Look for the product by name and note its version.
  2. Uninstall it, then install the package you have. Microsoft lists installing over an existing installation as a documented cause of 1603.
  3. Where a shortcut is the only thing missing, that is not a reason to reinstall; pin the application from Start instead.
  4. If uninstall itself fails, you have a different problem and a different article – a missing installer cache reports 1635, 1636, 1714, 1648 or 1603.

SYSTEM cannot write to the destination

You have this one if The log names a file or registry action and reports Windows error 5, access denied, immediately before the engine begins rolling back.

  1. Open the destination drive or folder’s properties, Security tab, and confirm SYSTEM is listed.
  2. Give SYSTEM Full Control and, under Advanced, set it to apply to this folder, subfolders and files.
  3. Wait for the permissions to finish applying to the whole tree before you retry.
  4. If the package sits on a network share, copy it locally first – part of the installation runs as SYSTEM, which usually has no rights to a share.

The destination is encrypted, or on a substituted drive

You have this one if The same package installs on one machine and not another, and the failing machine’s target path is encrypted or reached through a drive letter created with subst.

  1. Install to a folder that is not encrypted.
  2. Install to a drive that is not accessed as a substituted drive; use the real path instead.
  3. If the software must live in an encrypted location, install it elsewhere first and confirm the install itself is not the problem.

A vendor custom action fails

You have this one if The line above the failure names an action that is not one of the standard installer actions – something like a configuration or service-registration step.

  1. Note the custom action name and search the vendor’s own documentation and support site for it; they know what it does and you cannot.
  2. Check the dependencies such an action would need: the right .NET version, a Visual C++ runtime, a service that can start under the account it expects.
  3. Where the action runs a script, confirm the scripting engines are registered and Windows Script Host is not disabled by policy.
  4. Test once with real-time protection paused. A blocked script or a deleted temporary file produces this exact shape, and confirming it tells you what exclusion to ask for.

1627, ERROR_FUNCTION_FAILED, is the code you often see alongside this. Send the vendor the section of the log around the failure rather than the exit code; the exit code tells them nothing they do not already know.

Full reference

Logging, and how to turn it on for everything

/l*v is the switch that matters: Microsoft documents * as a wildcard meaning log all information except the verbose and extra-debugging options, so /l*v gives you everything except the extra debugging. The path you name must already exist, because the installer will not create the directory structure for you.

Flag What it logs
i Status messages
w Nonfatal warnings
e All error messages
a Start up of actions
r Action-specific records
v Verbose output
x Extra debugging information
* Everything except v and x; use /l*v to add verbose

To capture every installation on a machine without adding a switch each time, Microsoft documents a machine policy: a REG_SZ value named Logging under HKLM\Software\Policies\Microsoft\Windows\Installer, set to the same letters the /L option accepts. The installer then writes a log into the temp directory with a random name of the form MSI*.LOG. Two limits are documented and both catch people out: the policy is used only when logging has not already been enabled on the command line, and you cannot use + or * in the policy value. Turn it off afterwards – the logs accumulate quickly.

Placing the fault from the log

What the log shows near the end Where to look
A file or registry action with Windows error 5 SYSTEM’s permissions on the destination
A named custom action, then the rollback The vendor’s own logic: a missing dependency, a blocked script, a service that cannot start
Note: 1: 2732 A packaging fault: an action called the directory manager before it existed
A message that another version of the product is already installed An earlier or broken installation still registered
An abrupt end with no action named The engine was terminated, which usually means security software

Checking what is installed without making things worse

Do not use the Win32_Product WMI class to find out what is on a machine. Microsoft is explicit that the class is not query optimised: a query against it makes WMI enumerate every installed product through the MSI provider and parse the list sequentially, and that process starts a consistency check of the installed packages, verifying and repairing as it goes. Event 1035 then appears in the Application log for every product on the machine. Microsoft’s recommended alternative is the Win32reg_AddRemovePrograms class where Configuration Manager is present, and the StdRegProv registry provider where it is not.

Codes that are logged rather than returned

  • 1708 is an internal message – “Installation operation failed” – not a process exit code. If a deployment tool reports 1708, it read it out of a log or an event rather than from msiexec.
  • Event ID 11708 in the Application log is that same message written as an event, following Microsoft’s rule that Error table errors are logged with an ID of the error plus 10,000.
  • Event 11707 is the successful counterpart, and 11728 records a configuration change completing, which is useful when you are trying to prove an install actually did something.
  • Internal errors in the 2xxx range belong to whoever built the package. Nothing you change on the machine will fix a 2732.
  • 2762 is “Cannot write script record. Transaction not started”, which Microsoft attributes to a deferred custom action sequenced outside InstallInitialize and InstallFinalize. That is the vendor’s sequencing to correct, not yours.

Before you escalate to the vendor

  1. Reproduce with /l*v to a path that exists, from an elevated prompt, on a machine you can keep.
  2. Confirm the four documented conditions do not apply: already installed, encrypted destination, substituted drive, SYSTEM permissions.
  3. Note the last action in the log and the Windows error beside it.
  4. Send the vendor the log section around that action, the product version and the Windows build. An exit code of 1603 on its own tells them nothing.

Every code this article covers

Code What it points at Source
1603 ERROR_INSTALL_FAILURE: a fatal error occurred during installation, and the transaction was rolled back Microsoft Learn
1708 Installation operation failed – an internal installer message rather than a process exit code Microsoft Learn
1627 ERROR_FUNCTION_FAILED: the function failed during execution, most often inside a custom action Microsoft Learn
2732 Directory Manager not initialized: an action used the directory manager before it existed, which is a packaging fault Microsoft Learn
2762 Cannot write script record. Transaction not started – a deferred custom action was sequenced outside InstallInitialize and InstallFinalize, which is a packaging fault rather than a machine fault Microsoft Learn
Event ID 11708 Application log entry recording “Installation operation failed”: error 1708 written as an event under Microsoft’s rule that Error table errors log with an ID of the error plus 10,000 Microsoft Learn

Confirm the fix worked

  1. Re-run with /l*v and confirm the log ends with the installation completing rather than unwinding.
  2. The Application log carries an 11707 for the product rather than an 11708.
  3. The product appears in Settings under Apps, Installed apps, with the version you expected.
  4. The application starts, so you know the rollback did not leave it half-registered.
  5. A second machine of the same build installs the same package cleanly, which tells you the fix was general rather than local.

Questions people ask about this

Does anything here cost money?

No. Verbose logging, the permission checks and the destination changes are all built into Windows, and 1603 is never a licensing state. If a vendor tells you the fix is a paid upgrade, ask them which action in the log they are referring to.

Can I enable verbose logging for every install at once?

Yes. Create a REG_SZ value named Logging under HKLM\Software\Policies\Microsoft\Windows\Installer using the same letters the /L switch accepts – but not + or *, which the policy does not support. Logs then appear in the temp directory as MSI*.LOG. Turn it off afterwards.

Should I use Win32_Product to check what is installed?

No. Microsoft documents that querying it makes WMI enumerate every installed product and start a consistency check, verifying and repairing packages as it goes. Use Win32reg_AddRemovePrograms where Configuration Manager is present, or the StdRegProv registry provider where it is not.

The log names a custom action I do not recognise. Now what?

That is the vendor’s code and only they can say what it needs. Send them the log section around the failure. It usually turns into a missing prerequisite, a service that cannot start under the account it expects, or a temporary file the action could not write.

Why does the same package install on one machine and fail on another?

Start with the documented differences: an encrypted destination, a substituted drive letter, or SYSTEM missing Full Control on the target. Those three explain more cross-machine differences than anything in the package.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error 0x80072EFD: Store Downloads Fail Behind a Proxy or Security Suite Free Fix MSI 1639 and 1624: Invalid Command Line or Transform in Silent Deployments License Error MSI 1921 and 1923: Service Could Not Be Stopped or Installed by the Setup Free Fix 0x800F0906 and 0x800F081F: .NET Framework 3.5 Will Not Enable on Windows
← Back to Knowledge Base