Categories
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 –
http://www.msigeek.com/261/identifying-installation-failure-through-cas-using-msi-logs
http://www.msigeek.com/257/interpreting-windows-installer-logs

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

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:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem

    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.

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

Understand the Windows Installer Logs

Here’s a fantastic document by Richard on “how to interpret Windows Installer logs”. This is a very essential and a noteworthy bookmark for every packager and administrator. Especially, Don’t miss the Annotated Verbose Installer Log section; it has a pdf file, which contains a log file generated on Vista.

Special Thanks to Richard Mc Donald for this wonderful Document!

Click here to Download the Annotated Verbose Log 

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

How to Troubleshoot an error using Windows Installer Logs

When you need to troubleshoot a failing install, it is often useful to use the policy hive rather than the command line to catch things like repairs and multi-package installs. The Windows Installer Log comes in very handy in this case. The log can be generated 2 ways (Other than the usual Msiexec <misname> /l*v c:\testlog.log).

1. Registry Key
Start Registry Editor (Regedt32.exe), and then create the following path and keys in the registry:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Create keys:
Logging : voicewarmupx
Debug”=dword:00000007

The letters in the value field are the options that are available to use with Windows Installer logging. You can use the options in any order. Each option turns on a specific logging mode. The function of each option is as follows:

v – Verbose output
o – Out-of-disk-space messages
i – Status messages
c – Initial UI parameters
e – All error messages
w – Non-fatal warnings
a – Start up of actions
r – Action-specific records
m – Out-of-memory or fatal exit information
u – User requests
p – Terminal properties
x – Extra debugging information.
+ – Append to existing file
! – Flush each line to the log

* – Wildcard, to log all information except for the v option. To include the v option, specify *v.

It is recommended that you use this service only for troubleshooting. Leaving the service turned on creates a new Msi*.log file every time you use the Add/Remove Programs tool in Control Panel. This activity adversely affects system performance and disk space.

2. Modifying Group Policy
You can use Group Policy to enable logging by modifying the appropriate organizational unit (OU) or Active Directory Group Policy:
Click Start, and then click Run.

In the Open box, type gpedit.msc to start the Group Policy Editor.
Expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Installer.
Double-click Logging, and then click Enabled.
In the Logging box, specify the options for what you want to log.
After the installation\UnInstallation of the package check in %temp% for log files starting with MSI (eg.MSI8758d.LOG).

Categories
How-to Windows Installer, Application Compatibility and Deployments

Troubleshoot MSI Installation Issues and Functional Errors

If the application does not work after the install, there could be several possible reasons for this. I’ve tried to outline a few of the troubleshooting steps I take when I run into these types of errors. Read on to learn more. 

The application does not work in user context ie., locked-down environment. 
  • To test this, install the package and run the application under a local administrator account for the workstation.
  • If the application works under this account but not under a normal user account, then the following problems might be present.
  • Unable to write to drives/folders such as R:, C:\Program Files, C:\Windows, etc. which are read-only for normal users. If this is suspected then make the drives read/write for the user to test this. Check whether R:\ and other shared directories are mapped properly before installation.
  • Unable to write to registry keys. With the exception of HKCU and HKLM\SOFTWARE, all other hives are read-only for normal users. If this is suspected then make the hive read/write for the user to test this (use REGEDT32.EXE in W2000 and regedit in XP and Vista).
    In either case if such problems are encountered then the resolution of the problem should be to give the read/write access required for folders on the workstation or hives in the registry.

The application does not work because of missing component!

  • To test this, run the source or native install on a clean machine, and run the application.
    Note that this test can also be done, after the initial application capture. If it does not work, then it is reasonable to assume that the application install is missing some components for it to work or the application will never work on this environment.
  • If it seems as if a component is missing then it can be added.

Not everything has been captured.

  • To test this, install the source, compile the captured .wsi or .wse file and execute the resulting .msi or .exe on the machine, and run the application. If it works then this indicates that all was captured but perhaps too much was removed whilst creating the package or wrong versions of components were used from the originals.
  • In either case a reasonable next step is to perform a “gap capture” on the workstation on which the package has been installed and tested.
    To do this, run WfWI or WI on this workstation and perform a capture of the original native install on top of the Packages install. This will give a “gap capture” indicating the differences, or what has been left out.
    Look at the files and registry entries in the resulting .wsi or .wse.

This post outlined some actions to be taken in the event of a completed package not working when installed. Further it also provided some details of the most common problems and actions.