Dialog ICEs - MSI Validation

ICE17 checks for some common problems with the Control table, including the
following:


• PushButton controls without entries in the Event table
• Bitmap or Icon controls without entries in the Binary table
• RadioButtonGroup, ListBox, ComboBox, or ListView controls without
entries in the corresponding tables


ICE20 verifies that required dialogs are present and that they have the required controls. For example, there must be a FilesInUse dialog box and it must have a Listbox control and three PushButton controls with specific properties set.


ICE23 checks that the tab order is correct for every dialog. That is, it makes sure that there is a Control_First control specified for every dialog, and that the Control_Next properties for each dialog form a single closed loop.


ICE31 validates that any text styles used in the Control table are actually defined in the TextStyle table.


ICE34 checks for inconsistencies in the RadioButton table and the corresponding RadioButtonGroup controls. For example, it makes sure that the default value of the control is one of the values listed in the RadioButton table.


ICE44 checks the NewDialog, SpawnDialog and SpawnWaitDialog rows in the
ControlEvent table to be sure that these rows reference dialogs that actually exist in the Dialog table.

Property ICEs - MSI Validation

ICE05 checks to make sure that required properties, including ProductName, ProductLanguage, ProductVersion, ProductCode, and Manufacturer, are present in the database.


ICE16 checks the length of the ProductName property to make sure it does not
exceed the maximum allowed 63 characters.


ICE24 checks the data types of the ProductCode, ProductVersion, and Product-
Language properties.


ICE46 looks at the database for properties that differ only in case (for example, “MyProperty” and “myProperty”). Because the Installer is case-sensitive, such properties are treated as two distinct properties. This is usually not what the developer intended. If you really did want to have separate MyProperty and myProperty properties, you can ignore the warnings from this ICE.


ICE52 checks for private properties in the AppSearch table. All properties in the AppSearch table must be public properties (that is, their names must be entirely upper case).


ICE69 inspects strings of the Formatted data type, looking for [$componentkey] substrings. These substrings must refer to the same component that is referenced in the Component column of the table being inspected.

Action ICEs - MSI Validation

ICE12 is used to validate that type 35 and type 51 custom actions are properly positioned with respect to the CostFinalize action in any sequence tables. Type 35 custom actions must come after the CostFinalize action, and type 51 custom actions must come before the CostFinalize action.


ICE13 checks for dialogs in the Execute Sequence tables. Dialogs can only
appear in the UI Sequence tables.


ICE26 checks the Sequence tables to make sure that all of the required actions are present. It also makes sure that no Sequence table contains an action that is disallowed for that table.

ICE27 verifies that every entry in every Sequence table is either a standard
action, a custom action, or a Dialog name. It also checks the organization of each Sequence table to be sure that actions are being performed in the proper order.


ICE28 looks at ForceReboot actions, and makes sure that they are not being
called in inappropriate places.


ICE63 checks the sequencing of the RemoveExistingProducts action. This action may be placed in several spots in the Sequence tables, but there are other spots where it is invalid.


ICE68 checks the Type column in the CustomAction table. Only some numbers
are valid custom action types. For example, a value of 82 in this column (which is not a valid custom action type) would generate an error from this ICE.


ICE72 checks the AdvtExecuteSequence table to make sure than any custom
actions it contains are type 19, 35, or 51. If this table contains other types of custom actions, advertisement may fail.

File and Registry ICEs - MSI Validation

ICE04 checks to make sure that all files have sequence numbers that make sense when compared to the information in the Media table. It finds the largest LastSequence value in the Media table, and makes sure that the value for the Sequence column in every row of the File table is less than this value.


ICE30 checks that the same file is never installed in the same directory by two
different components in the same Installer package (doing so would break the reference counting scheme of the Installer). It considers both long and short file names, and looks at what will happen if Condition columns evaluate to either true or false.


ICE33 validates that all entries in the Registry table should be in that table. Some Registry information should be made through the more specialized tables in order to support advertisement and install-on-demand. This includes information that belongs in the Extension, ProgId, Verb, MIME, Class, Typelib and AppId tables. If this ICE detects any problems it will tell you which entries you should move and which tables you should move them to.


ICE42 inspects rows in the Class table for InprocServer32 Registry entries. It
makes sure that these rows do not refer to an .exe file in the File table, because inprocess servers must be .dll files.


ICE49 inspects the data type of default Registry entries (those with a null in the Name column). Such entries must use the REG_SZ data type.


ICE53 presents a warning if the Registry table tries to modify the Installer policy by writing to keys underneath Software\Policies\Microsoft\Installer.
Any changes made to these keys are better made by setting the values of the properties that control the Installer’s actions.


ICE60 looks at file version information in the File table. If a file is not a font and it has a version, then it must also have a language. If you ignore warnings from this ICE, then repairs will tend to reinstall files needlessly. That’s because the file on disk will always have a language, even if the entry in the File table does not. The Installer will see this as the installed language not matching the language in the package, and so will reinstall the file.


ICE70 checks Registry entries that write integers to make sure that the integers are specified properly. For example, ##5 or #x12A4 are valid, but #zzy27 is not.

MSI Validation - Feature and Component ICEs

ICE02 checks to make sure that you’ve got the relations right between the Component, File, and Registry tables for KeyPath columns. You’ll recall that the KeyPath column in the Component table points to either an entry in the File table or an entry in the Registry table. The corresponding entry in those tables must point back to the same record in the Component table that points to it. ICE02 verifies that this circular relationship has been properly set up.


ICE08 makes sure that there are no duplicate GUIDs in the Component table.


ICE09 checks that any component being installed into the SystemFolder folder
has its permanent bit set. It’s a violation of the Installer guidelines to install nonpermanent components to this folder.


ICE10 looks at feature hierarchies and advertisement. If a parent feature is set to favor advertisement, all of its child features must be set to favor advertisement as well. If a parent feature is set to disallow advertisement, then all of its child features must be set to disallow advertisement.


ICE14 makes two checks in the Feature table. First, it verifies that the root feature is not set to “follow parent” status, because it has no parent. Second, it makes sure that no feature is its own parent.


ICE18 verifies that any empty directories used as the KeyPath column for a component are listed in the CreateFolder table.


ICE19 checks that advertised components use a file as their key path, rather than a folder or a Registry key.

ICE21 uses the FeatureComponent table to verify that every component in the
Component table is assigned to at least one feature.


ICE22 validates that the FeatureComponent and PublishComponent tables do
not conflict. The FeatureComponent table assigns components to features, and the PublishComponent does the same. The two assignments must be the same in all cases.


ICE35 checks components that are stored in compressed fashion in CAB files. In particular, it makes sure that these components are not set to run from source.


ICE38 checks components that are installed to a particular user’s profile (for
example, to the predefined StartMenuFolder or DesktopFolder). Such components must use a Registry key as their key path, and this Registry key must be located in the HKEY_CURRENT_USER Registry hive.


ICE47 looks at the Feature and FeatureComponents tables to locate features that refer to more than 800 components. Such features will cause trouble on Windows 9x systems. It also checks that no feature has more than 1600 components, which is the absolute limit on Windows NT and Windows 2000 systems.


ICE54 looks for components whose key path files are companion files (that is,
whose key path files reference another file for version information). Key path files must have explicit version information in the File table.


ICE57 makes sure that components do not mix per-machine and per-user data.
It checks the Component, File, Registry, and Directory tables. For example, a component that installs files to the DesktopFolder and Registry keys to the
HKEY_LOCAL_MACHINE hive would fail this ICE.

MSI Validation - Base ICEs

ICE01 tests to make sure the ICE mechanism is functioning. All it does is return the time that it was invoked. ICE01 should never fail. If it does, something is wrong with the Installer Service on the computer where you’re running validation.

ICE03 check the basic items that internal validation should check during editing. It can detect a variety of conditions, including the following: 

• • Duplicate primary keys
• • Nulls in Non-nullable columns
• • Foreign keys that reference nonexistent rows
• • Values outside of acceptable ranges
• • Invalid GUIDs
• • Improperly formatted Condition columns
• • Mistakes in the _Validation table itself

ICE06 performs a sanity check on the .cub file itself. It checks to make sure that the database being validated contains every column that is being checked by any of the ICEs. If this ICE fails, it most likely means that you’re using a new version .cub file with an older version of the Installer database.

ICE32 looks at Foreign Key columns and makes sure that they are the same size and data type as the Primary Key columns that they’re referencing. As long as you’re only using the standard tables in your Installer database this ICE should never fail.

MSi Sequence Column Values of Sequence Tables

Values for the Sequence Column of InstallUISequence, InstallExecuteSequence Tables

• Positive number  Run the action in this sequence.
• Zero Don’t run this action.
• Null Don’t run this action.
• -1 Run this action when an installation is successfully completed.
• -2 Run this action when the user cancels during an installation.
• -3 Run this action in case of a fatal error.
• -4 Run this action when the installation is suspended.
• Other negative numbers Don’t run this action.