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

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

Run and log opt

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.
Run log summary

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:

0Action not executed
2User canceled
3Fatal error
4Suspended, waiting for reboot

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.

NoteWhen 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:

Log entryValueDescription




Component or feature is currently installed to run locally.

Component or feature is currently installed to run from source.

Feature is currently advertised. Only features can be advertised, components cannot be.

Component or feature is not currently installed.







No request.

Installation requests component or feature be uninstalled.

Installation requests component or feature be installed to run locally.

Installation requests that component or feature be installed to run from source.

Installation requests feature be installed as an advertised feature.

Installation requests feature be reinstalled. Components do not use reinstall state.

Installation requests feature be installed in the default authored install state.








No action is done.

The installer actually uninstalls component or feature.

The installer installs component or feature to run locally.

The installer installs the component or feature to run from source.

The installer installs the feature as an advertised feature.

The installer reinstalls feature.

The installer installs the feature in the default authored install state.

The installer uninstalls component's files and leaves all other resources of the component installed.

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.

6.1 Different UpgradesCode

If an upgrade is not performed, the first step to start the investigation is to see if the installation packages have the same UpgradeCode, as is mandatory to have it the same.

The UpgradeCode is a GUID representing a related set of products. A set of different versions of your application will have the same UpgradeCode. This enables newer versions of your application to search and upgrade previous versions installed on the same computer.

If the same UpgradeCode is used, then you can start searching through the log and see if an older version is found. During the FindRelatedProducts standard action, older or newer versions of the package are searched. If an older version is found, its Product Code is placed in the "OLDPRODUCTS" property. In the log, it should be something like:

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}'.

The old installation package is removed during the RemoveExistingProducts standard action. If the old installation package is properly removed, then you should see something similar in the log:

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

In order to search through the log for this case, use the following keywords:

  • FindRelatedProducts
  • RemoveExistingProducts

As a general rule, to check if the old installation package is identified search for the OLDPRODUCTS property. If this property is set, there should be something like that in the log:

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

6.2 Different Installation Type

A case when an upgrade is not performed is when the installation type is different between two versions.
For example, if the old installation package was installed per-machine and the new installation package have the install type set to a per-user installation, the upgrade will not be performed and the two programs will be listed side by side in the Programs and Features list from Control Panel. Also, you should see something like that in the log:

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...

NoteA per-user installation cannot upgrade a per-machine installation and a per-machine installation cannot upgrade a per-user installation.

If you are aware of this but you need to change the installation type, in order to uninstall the old installation package, you can use the predefined uninstall previous versions custom action. You can add this custom action in the Custom Actions page.

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.