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