How Do I Debug a Windows Installer Verbose Log File?

Understanding Microsoft Installer Logs

This article explains the main concepts of how to read and debug a verbose log file created by the Windows Installer.

• 1. Summary test
• 2. Launch the package in debug mode from Advanced Installer
• 3. Analyzing the Windows Installer log file
• 4. Checking the Installation Status of Features and Components
• 5. Tips for the Windows Installer log reading
• 6. Check why an upgrade is not performed
  • 6.1 Different UpgradesCode
  • 6.2 Different Installation Type
• 7. Debugging tools

1. Summary test

During the installation, you may get errors that provide insufficient information about what has occurred. In this case, it is very useful to create the MSI installer log to gather more information about the installation process. This may allow you to resolve the problem yourself or provide vital information to Advanced Installer Technical Support.

By default, logs will contain things such as:

• Errors that occur during the installation including internal Windows Installer errors
• All standard actions executed as well as any custom actions that were executed and their return codes
• Values of Windows Installer Properties, including details of any changes
• The source location of the setup
• If the installation was completed
• If the installation was rolled back
• Whether the user canceled the install

2. Launch the package in debug mode from Advanced Installer

Check the Show run Log option and press the [ Run ] button to run the installer in debug mode. The resulting Windows Installer log will be shown in the “Run Log” Panel.

In the bottom of your Advanced Installer project, the Run and Log panel will be displayed. Useful information can be found as they are displayed in the installation process.

After the installation process is complete you can navigate through the log file using the left tree from the Summary panel.
Easily navigate through:

• Policies
  • Per-User
  • Per-Machine
• Resources States
  • Feature
  • Component
  • File
• Properties
  • Added
  • Modified
  • Deleted

When testing on other machines, for creating a verbose installation log, you can use a command line which looks like this for MSI packages:

        msiexec /i "C:\MyPackage\Example.msi" /L*V "C:\log\example.log"
      

and the following for .EXE packages:

        mySetup.exe /L*V "C:\log\example.log"
      

Using the above command line option, the statement will be passed by the bootstrapper to the MSI and the log will be created.

3. Analyzing the Windows Installer log file

The installation of an MSI file is a series of actions. These can be standard actions or custom actions. Each action that is performed has an associated Return Value. The possible return values are:

Looking at the table above, you can see that a return value of 3 is useful. In Notepad, use the Find command and search for value 3. There may be multiple instances of return value 3 in the log file, so how do you determine which caused the installation to abort? When return value 3 is found in the file, start reading upwards from the error in the log file and see what actually cause this.

If a fatal error occurs and the installation aborts, the MSI package initiates a rollback procedure. If the installation is unsuccessful, the installer automatically performs a rollback installation that returns the system to its original state.

By manually searching through the log file, you may encounter a bunch of continuous lines with FileRemove or ComponentUnregister.
The rollback is important because the fatal error that caused the install to fail typically occurs right before the rollback process begins. Also, you can simply search through the log for Rollback.

So, for each standard action or custom action executed, its return value is displayed in the log (e.g. Action ended 16:34:29: InstallFiles. Return value 1.).

In the example above, we see that the return value for the InstallFiles standard action was 1 meaning the action completed successfully. If this action failed and caused an error, a return value of 3 would have been returned and would have caused the rest of the installation to stop and the rollback process would begin which would return the system back to the same state before the installation began.

When the language identifier for the current user is different than 1033 (non-English - United States), you would see its corresponding translation (e.g. Aktion beendet um 16:23:32: InstallFiles. Rückgabewert 1. for UserLanguageID = 1031).

4. Checking the Installation Status of Features and Components

Having the log file you may need to verify that a particular feature, component or file has been installed.

The verbose log includes an entry for each feature and component the installation package may install. The log tells what the state of that feature or component was prior to the installation, what state was requested by the installation, and in what state the installer left the feature or component.
Features and components entries appear in the log as in the following example:

    MSI (s) (C8:0C):   Feature:   myFeature; Installed: Absent;   Request: Local;   Action: Local
    MSI (s) (C8:0C): Component: myComponent; Installed: Absent;   Request: Local;   Action: Local
      

In the verbose log it can be seen that:

• The installation state of the feature and component was absent before running the package
• The installation package requested a local installation of these
• The feature and component were both installed locally

The following table summarizes the possible component or feature states that can appear in the log:

In order to check for the features and components states, please search for the InstallValidate standard action. After the standard action is marked as the current action which is being executed, on the following lines in the log, the features and components state is displayed.

5. Tips for the Windows Installer log reading

The verbose log can give you useful information about the installation process and some explanation about this. For example:

Disallowing uninstallation of component: GUID's component since another client exists

Basically, this can happen if the same components are shared between multiple packages installed on the same machine. Windows Installer keeps a refcount for the components and does not allow removing them until all the applications that use them are removed.

Also, this may happen if you duplicate the project file (saved under a different name or used the "copy-paste" method). It is strongly recommended not to do this because the created project will have the same GUIDs (Upgrade Code, Product Code, components ID) as the source/original project. To avoid this, you must use the Save as template option.

If during an upgrade operation there are files missing from the installation folder, then search through the log for the following message:

Disallowing installation of component: GUID's component since the same component with higher versioned keyfile exists

If you found it, then this is the reason why your file is not copied on the target machine.
The upgrade process performs the following actions:

• Detect and completely remove older products. During this operation, the file will be removed from the machine.
• Install the new product. The file from the upgraded version will not be installed since its component was not marked for installation.

To overcome this behavior, you can enable the Always overwrite existing file option from the File Operations Tab of the File Properties.

MSI (s): File: C:\MyApp\MyExe.exe;  Won't Overwrite;  Existing file is of an equal version

This indicates that the installation package will not overwrite the existing file since is the same version as the one being installed.

6. Check why an upgrade is not performed

When performing an upgrade, you may encounter the case where the old installation package is left behind and the new package is listed side by side with the old one in the Programs and Features list.
This may happen if the previous version of the installation package is not detected.

FindRelatedProducts: Found application: {54737F41-13B0-4B98-9C70-F6C07F471E39}
MSI (c) (E0:4C) [17:14:09:576]: PROPERTY CHANGE: Adding OLDPRODUCTS property. Its value is '{54737F41-13B0-4B98-9C70-F6C07F471E39}'.
MSI (c) (E0:4C) [17:14:09:576]: PROPERTY CHANGE: Adding MIGRATE property. Its value is '{54737F41-13B0-4B98-9C70-F6C07F471E39}'.
 

Action start 17:14:13: RemoveExistingProducts.
RemoveExistingProducts: Application: {54737F41-13B0-4B98-9C70-F6C07F471E39}, Command line: UPGRADINGPRODUCTCODE={C64CA371-69F2-473C-83C1-82B8B313C846}  CLIENTUILEVEL=0 REMOVE=ALL
      

Property(S): OLDPRODUCTS = {54737F41-13B0-4B98-9C70-F6C07F471E39}
      

Action start 16:24:46: FindRelatedProducts.
MSI (c) (10:FC) [16:24:46:131]: FindRelatedProducts: current install is per-user.  Related install for product '{8E38592C-391E-4212-BC31-376A37BB6968}' is per-machine.  Skipping...
          

7. Debugging tools

• Using the Advanced Installer environment
• Utilities as Wilogutl

The Run and Log option from Advanced Installer can help you create a verbose log and offer you the possibility of a dynamical walkthrough. However, when testing on different machines, like test machines you get a log file. In this case, you can use the Wilogutl.exe which can help you read the log.

Wilogutl.exe assists the analysis of log files from a Windows Installer installation, and it displays suggested solutions to errors that are found in a log file.
This tool is only available in the Windows SDK Components for Windows Installer Developers.