MSI Package Validation: How to Fix Errors

How can you ensure that MSI package has been built properly and the package structure is correct? Run validation on MSI package.

Whether you have created MSI from scratch or converted it from EXE, validation is a must-have step.

Validation of MSI packages checks the MSI-file database for authoring errors, because a package installation that does not pass the validation can damage user’s system. Taking into account the importance of the creating error-free MSI packages, we’ll review the principles of MSI package validation, the process itself, and also talk about how to fix MSI errors.

Principles of MSI Package Validation

According to MSDN, MSI package validation includes the following three processes:

• Internal Validation is performed in real time while you are editing MSI table records. This kind of validation checks if entered data is syntactically correct. Specifications for this validation are maintained in _Validation table.
• String-Pool Validation. The Windows Installer stores all database strings in a single shared string pool to reduce the size of the database and to improve performance. The only means of validating the string pool is to use the “MsiInfo” tool found in the Windows Installer SDK.
• Internal Consistency Evaluators – ICEs is a scan of MSI database for entries in database records that are valid but that may cause incorrect behavior in the context of the whole database.

What Are the Internal Consistency Evaluators (ICEs)

Internal consistency evaluators, also called ICEs, are custom actions written in VBScript, JScript, or as a DLL or EXE. ICE custom actions return four kinds of messages:

• Errors Error messages report database elements that cause incorrect behaviour. For example, duplicate component GUIDs cause the installer to incorrectly register components.
• Warnings Warning messages report database elements that cause incorrect behaviour in certain cases. Warnings can also report unexpected side effects of database authoring, for example, entering the same property name in two conditions that differ only by the case of letters in the name. As the installer is case-sensitive, the installer treats these as different properties.
• Failures Failure messages report the failure of an ICE custom action. Failure is commonly caused by a database with such severe problems that the ICE cannot even run.
• Informational messages Informational messages provide information from the ICE and do not indicate a problem with the database. Often they inform about the ICE itself, such as a brief description. They can also provide progress information as the ICE runs.

ICEs check the MSI package database for the violation of rules. Many of these violations are serious, such as component IDs duplication in the same package or a component ID with lowercase letters. All errors reported by an ICE validator should be fixed, and you should pay attention to all the warnings.

For full ICEs description please read ICE Reference in MSDN.

Validating MSI Package against Standard and Custom CUB files

After selecting the appropriate ICEs for MSI package validation, you must collect the custom actions together into an ICE database – a .cub file. A .cub file is a standard .msi database that contains only ICEs and their required tables and is used only to store and provide access to ICE custom actions.

A .cub file contains the following database tables:

As .cub file is an MSI by nature, it can be created (opened/changed) with any MSI-editing tool – e.g. MSI Editor (try it now for free).

To validate a database, at first a .cub is merged to the database, then ICEs are executed and the results of execution are reported. Most ICE validation tools merge the .cub file and your database into a third, temporary database. Windows Installer displays warnings, errors, debugging information, and API errors as it executes each ICE in the .cub file. When the installer finishes executing the ICEs it closes the .msi file, .cub file, and temporary database without saving any changes. The .msi file and .cub file remain unchanged by the validation test.

Microsoft supplies several .cub files in the Microsoft Windows Software Development Kit (SDK):

• darice.cub – provides Full MSI Validation(all standard ICEs)
• logo.cub – provides validation against Windows Logo Program requirements
• XPlogo.cub – provides validation against Windows XP Logo Program
• Vstalogo.cub – provides validation against Windows Vista Logo Program
• Mergemod.cub – provides validation of merge modules

Logo cubs contain subsets of ICEs from darice.cub, while Mergemod.cub has also ICEs – ICEMs – relevant for merge modules only.

Authors of installation packages can write own ICE custom actions, providing specific checks that apply to their packages. In this case, custom .cub files are designed to provide specific validation.

When performing the validation in MSI Editor, go to Menu -> Validation – two .cub files are provided for selection via menu – “darice.cub” (Full MSI validation suite) and “Mergemod.cub” (Merge module validation suite):

You can also validate the MSI using a custom CUB file.

During the validation process, you generally get some errors and warnings – relevant tables(1) and fields(2) are marked with red color, and complete information about particular problem is given on ICE Validation(3) tab:

When validation process is finished, it is time to review MSI package validation results and resolve validation problems where appropriate.

Fixing ICE Validation Errors

First, we have to mention that not all MSI package validation errors/warnings are critical. You have to consider the criticality of each one and decide whether to fix it or not.

The process of fixing validation errors implies making changes to installation database in order to achieve the state when they can pass the validation. Package functionality, on the other hand, should not suffer during the process. Therefore, sometimes fixing ICE errors is a matter of compromise.

MSI package validation issues are fixed one-by-one. In some cases, the same database entries are the subject of more than one issue, so few validation problems can be fixed with a single change in the database. Fixing ICE errors is an iterative process, as changes made to the database to fix particular errors can result in new validation issues. So “fixed” database must be revalidated at each iteration, until the desired results of validation are achieved.

The Review of the Common Validation Errors

Now, you are equipped with all the necessary information about MSI package validation. Practice fixing validation errors in your packages and do not forget to use the information above and information from ICE Reference.