How-to Microsoft Windows Installer, Application Compatibility and Deployments

Troubleshoot the error 1603 “Fatal Error During Installation”

This error message is displayed by the Microsoft Windows Installer Engine (Wondering whats this? Read here) and is a general error code that indicates a problem occurred during the installation. Read on this article to learn how to sidestep this speed bump. The following is the probable list of known causes for this error to occur:

  • Short file name creation is disabled on the target machine.
  • An Install Script custom action is prototyped incorrectly.
  • A file is locked and cannot be overwritten.
  • The Microsoft Windows Installer Service is not installed correctly.
  • The Windows Temp folders are full.
  • The setup was corrupted after installation and, therefore, fails with this error during un-installation.
  • An older version of Install Shield Developer is being used.
  • Print and File sharing is not installed if your application needs it.

Troubleshooting 1603 MSI Error

As discussed, The 1603 error code is mostly returned when any action fails during an installation on Windows, and most commonly it indicates that one of the custom actions in the MSI failed. When we encounter a failed setup with return code 1603, here are the steps that we should follow:

Re-run the setup with verbose logging enabled using steps similar to those that are listed here.

Step 1: Generate a verbose log file named msi*.log in the %temp% directory the next time the setup package is executed. (Click here to know more ways to generate log). Know more about the command-line switches here.

msiexec /i <msipath>setup.msi /l*v c:\temp\msi.log

Step 2: Open the verbose log in a text editor such as notepad and search for the string “return value 3”. In nearly all cases, this will take us to the section in the verbose log that lists the action that failed that initially caused setup to rollback.

Step 3: Review the contents of the log file immediately above the “return value 3” string to determine which custom action or standard action failed. Depending on which action is failing, We will need to proceed to more detailed debugging from here.

One can find that the biggest hurdle to debugging a failed setup is often zeroing in on which part of the setup is actually failing, and this trick of searching for “return value 3” ends up helping speed this process up in nearly all cases. Of course, it does not work in 100% of scenarios.

You can find some ways of troubleshooting the logs here –

“Access your favorite Windows Applications from your Android/iOS device with a virtual desktop by of the best Desktop as a Service providers. Get a free trial of Office 365 and excellent support by

Known Solutions

The following solutions have resolved this error in the majority of cases:

  1. Make sure short file name creation is enabled on the target machine. You can check to ensure that the target machine does not have short file name creation disabled by navigating to the following registry entry:

    Make sure the value “NtfsDisable8dot3NameCreation” is equal to 0. This indicates that short file name creation is enabled. A value of 1 indicates that this functionality is disabled. You should change the value to 0. After modifying this value, the target machine should be rebooted before attempting to launch the setup again.

    Note: If the target machine should normally have short file name creation disabled, it can be disabled after the install completes by resetting “NtfsDisable8dot3NameCreation” to 1 and rebooting.
  2. To ensure that the Windows Installer Service is properly installed and configured, it is recommended that users install the file InstmsiA.exe on Windows 95/98/Me or InstmsiW.exe on Win NT systems. These files are shipped with your InstallShield product and are located in the following location: <Product Path>\Redist\Language Independent\i386. If the service is installed, to know the status of the service exection, you could also goto services.msc in the command prompt, check the status of the Windows Installer Service. “Stopping and restarting it can help”
  3. Empty all temporary folders. The specific temporary folders for a machine can be determined by accessing the DOS prompt and typing set. Note the values listed for TEMP and TMP, and delete all files in those locations.
  4. Make sure no other applications, including utilities such as virus scanners, are running in the background. Close all running applications and utilities, and launch the installation again.
  5. If this error occurs during un-installation, use the Microsoft Windows Installer CleanUp utility to uninstall the installation. Once the installation has been successfully un-installed, you can then debug the project to determine what caused the original error.

If it doesn’t fall in this last, it could be any other error which occurred during the installation, do update in the comments..lets fix that..!

LinkedIn and other Discussions

I had also posted this on LinkedIn Discussions and have got some quality responses for the same – I will extract some information from there and post it here so that, you can get all the information at one single place.

A Senior Desktop Analyst, Jack Fei writes,

Vijay has makes some excellent points about how to troubleshoot these types of issues. From my experience, the fix is usually trivial once you understand “how to correlate verbose logging results” with msi internals.

First, know that “installation” means msiexec.exe sequentially processing rows of the InstallExecuteSequence table inside the msi database.

Second, know that msiexec.exe processes the commands sequenced between InstallInitialize and InstallFinalizes in two passes. A way to think about it is the first pass “conditionally installs the change” to the machine while checking the syntax of the command and the second pass “commits the change to the machine”. A 1603 essentially means “an error occurred” trying to commit the change, causing msiexec.exe to “backout the change”.

This type of error is either caused by msi misengineering (most vendor msi are misengineered) or by an “machine specfic issue”. So Patrick Pepin makes an excellent suggetion to check the msi vendor.

Having VMWare or imaging tool really helps troubleshoot this type of issue.

1. I would determine the issue can be reproduced on a clean machine with all pre-requisites installed (just to eliminate the possibility false negative caused by testing on an unknown or corrupt pc environment).

2. If it is a capture msi (original source is non-msi) I would systematically exclude files and registry keys until I isolated the component causing the issue in my msi. I built it, so I know best how to fix it.

3. if the msi was engineered by another vendor, I would review the verbose log and isolate the failing instruction in the InstallExecuteSequenceTable. My major technique was to find the failure that generated the “1603” error and find the likely instruction that caused it. To test my theory, I would comment out only that instruction (put a negative sign in the sequence column) and rerun the command. Sometimes, I would get lucky and even “work around” the msi defect by leaving the custom action commented out. This type of change works great when the custom action is doing “unnecessary checks” for desktops in your environments. Obviously, I would “test the modified msi” and make sure the application installed and starts cleanly.

4. If I can reproduce the problem on a clean desktop, I will have good ammunition to contact the vendor. However, my experience is if you know how to do what I have outlined, you will exhaust the technical support departments of whatever vendor you call. This is done for “political reasons” more than anything else – so you can be the hero when the vendor despite considerable persistance from you, can not find a solution.

Good luck. Hope this helps.

Guest Posts How-to Windows Installer, Application Compatibility and Deployments

Command Line Switches for MSI and MSP Installations

thumbHi Folks, Its time for yet another Guest Post; and we have Bhuvana writing for us. In this article she focuses on the command line arguments and the silent switches that can be used for msi and msp (un-installable patches). Bhuvana specializes in InstallShield & MSI Installers and her primary responsibility at work is “Build & Release” which includes creating Setups and Source Control Management.

She keeps all the details crisp in this table. I know that, this below chart will be as a printed one.. in your desks !!

Install / Uninstall Command Line Option Silent Mode
MSI – Installation  msiexec /i “<msi file name with path>” [TRANSFORMS=”<mst file name with path>”]  msiexec /i “<msi file name with path>” [TRANSFORMS=”<mst file name with path>”] /qn
MSI – UnInstallation  msiexec /x <ProductGUID> msiexec /x <ProductGUID> /qn
MSP – Installation Command line with Progress dialog:
msiexec /p “<msp file name with path>” /qb
msiexec /p “<msp file name with path>” /qn
Command line with UI:
msiexec /p “<msp file name with path>” REINSTALLMODE=oums REINSTALL=ALL
MSP – Uninstallation Command line with Progress dialog:
Msiexec /package <ProductGUID> MSIPATCHREMOVE=<PatchGUID> /qb
msiexec  /I <ProductGUID> MSIPATCHREMOVE=<PatchGUID> /qn

  1. Patch uninstallation does not work without /qb option. i.e. Patch can be uninstalled from command line only in silent mode. If you want to invoke the UI for uninstallation, go to Add / Remove Programs with Show Updates enabled.
  2. Msiexec /uninstall <PatchGUID> /package <ProductGUID> /passive
    The above command removes the entire base product but not the Patch alone.

Bhuvana’s Thought on
I came across MSIgeek blog through linkedin groups. Good to see lots of articles and FAQs on MSI at one stop. Some of the articles definitely helps to give a better insight into the concepts. So felt like contributing some article, which would help people like us, the Packaging specialists.

If you want to get in touch, her LinkedIn Profile is – Here. (PS: Do mention in the LinkedIn request that, you read her article on msigeek. We do not want to give her un-necessary Spams 🙂 )

How-to Microsoft Tools Windows Installer, Application Compatibility and Deployments

Creating your first WiX project

The Wix tools allow you to define the structure of a windows installer package using an XML file. This gives you all of the usual benefits of XML: easy editing with a variety of tools, the ability to modify the files using well-known technologies, and the ability to put the source file under source code control, for ex. the Wix tools themselves are command-line tools, so they fit well with almost any build process. In this post, we will look at creating a WiX project using Visual Studio.

A little note on MSi Engineering
Windows Installer setup package can be described as a three-level hierarchy. The product is at the top of that hierarchy. Users can interact with a Windows Installer setup package at the product level, as during a default or typical install, or they might interact with the setup package at the features level, as during a custom install. Developers, on the other hand, have to interact with the setup package at the component and individual resource level.

Packages are built from components. A component is a group of one or more related resources—files, shortcuts, registry entries, etc.

Components are grouped into features. A feature is a group of one or more components that are installed together. A component can belong to one or more features, but each component is installed only once on a give machine.

Every Windows Installer product, package, and component is identified internally by a unique GUID. The product code GUID remains constant for all releases within the same major version of a product. The package code GUID changes for each build that is released into the wild. The component code GUID changes according to the rules governing components.

For more information on Component Rules Click Here

Starting a WiX project in Visual Studio

Step 1: Launch Visual Studio, and create a new project.

Step 2: Select Setup Project, Windows Installer XML Section

Step 3: Your first Wix Script and template is ready, you will get intuitive help when you start typing – Thanks to Votive

Explaining WiX script Elements

The product element defines the product that the installer will install. The name of the element corresponds to a table in the windows installer database, and the attributes correspond to the columns in the table. For instance, the installer database includes foreign key columns to relates many tables, while the WiX source files use nesting to accomplish the same relation. The WiX tools take care of defining the appropriate foreign key values for you.

–Package Id=”6697CCC3-B351-4DCE-820E-DEAC87F57A2A” Comments=”Demo Installer” Manufacturer=”” InstallerVersion=”200″ Languages=”1033″ Compressed=”yes”

Within the product element, you’ll find a single package element, defining the package that corresponds to this WiX file.

–Media Id=”1″ EmbedCab=”yes” Cabinet=””

The media element defines the distribution media where the MSI file and any associated CAB files will be stored.

The directory elements define the hierarchy of directories that the installer service will use with this software. Note that the Id attributes are not completely arbitrary. The windows installer defines a number of special directories, including the two (the program files folder and the program menu folder) that I’m using in this example.

The Component elements and their child elements define the exact software that will be installed. In this case, the first component consists of a single file, while the second includes a file and a shortcut to the file. Note that WiX will look for the files that you include relative to the XML file. The best plan is probably to place the XML file in the same folder as your source files, and place the wix tools on your path.

The feature element defines both the single feature in this package and the mapping between features and components.

One will need both the Windows Installer SDK and the WiX documentation to develop Wix Scripts and MSis.

Microsoft Tools Windows Installer, Application Compatibility and Deployments

WiX v3.0 now available for download

The final build of WiX v3.0 is 3.0.5419 has been released to SourceForge and marked RTM/stable. You can download it from

Also, Votive is now available for Visual Studio 2010 beta. I would suggest all Visual Studio 2010 Beta users to upgrade to the latest build of WiX v3.5 to try out the feature. You can download it from
You also get,
A new set of detection properties for .NET Framework 4 beta installation states in the WixNetfxExtension
A new set of detection properties and registration custom actions for Visual Studio 2010 beta editions in the WixVsExtension.

Call to Actions
Votive –
WiX v3.0 online documentation –
Rob Mensching’s announcement about the release of the final version of WiX v3.0 –
Tips to migrate from wix v2 to wix v3
Bob Arnson’s announcement –
WiX site on SourceForge
WiX tutorial

Folks, who aren’t aware about WiX….
The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset provides a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages.

WiX is an open source project, originally developed by Microsoft and maintained by Rob Mensching. You can download the latest binary and source code releases from SourceForge. This tutorial originally describes version 2.0, the stable release. Version 3 is still under development and although it is still a moving target, we have started to add material that describes the changes brought about by the new version.

The toolset is written in C# and requires the .NET Framework 1.1 and its Service Pack 1 to run. However, this only applies to the toolset itself. The installation packages you create with the toolset do not require any extra framework or software to be installed on the target computer. Similarly, there might be a few additional utilities required for some special applications (merge modules, patches) but only on your build computer, the client will only need the finished and self-contained installer package, nothing else.

Join WiX Group:
There is a friendly community of Wix developers and users in a dedicated mailing list, hosted at SourceForge. This is the best place to ask for advice about any aspect of WiX. If you already have a SourceForge account, you can join on the website, too, but the simplest way is to send an empty message to the subscription address.

How-to Windows Installer, Application Compatibility and Deployments

Access MSI Database in Deffered Context through Custom Actions

Deferred custom actions have limited access to the installation session. If your deferred custom action requires information about the installation that it cannot obtain through its limited access, then you can provide that information to the deferred custom action through the CustomActionData property. This method is only available to script and DLL deferred custom actions.

“How-to” make this work??

1.An immediate custom action that executes before the deferred custom action sets a property with the same name as the deferred custom action to the value that is needed by the deferred custom action. So, if the primary key for a deferred custom action is called “DeferredCA,” then the immediate custom action would set a property called “DeferredCA” to the value that was needed. A type 51 custom action would be an easy way to set this property. Another method would be an immediate custom action that calls MsiSetProperty with the szName parameter equal to “DeferredCA.” Note: The action name is case-sensitive.

2. When the deferred custom action is queued into the installation script, the installer will write the value of the property “DeferredCA” into the installation script as the value of the property CustomActionData.

3.Upon execution, the deferred custom action retrieves the value by making a MsiGetProperty call with the szName parameter equal to “CustomActionData.” Alternatively, a script custom action would use the Property property of the Session object

How-to Windows Installer, Application Compatibility and Deployments

Installing Specific Features in a MSI Package

The ADDLOCAL, ADDSOURCE, and ADVERTISE properties can be used to install only a certain number of known features.

The following command-line script would be used to install the “Word” and “Excel” features of the example.msi package locally on the machine. Feature names are case-sensitive.

msiexec /i example.msi ADDLOCAL=Word,Excel /qb

The following command-line script would advertise the “Excel” feature and install the “Word”feature to run from source.

msiexec /i example.msi ADVERTISE=Excel ADDSOURCE=Word /qb

Windows Installer, Application Compatibility and Deployments

Key Information on Sourcelist of a MSI

The following registry key gives information about the sourcelist for a msi. (Source Resilency)

We can also check for the transforms which were installed along with msi in