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.

Resolve ICE43 Error

Error: Component “…” has non-advertised shortcuts. It Should use a registry key under HKCU as its KeyPath, not a file.

Solution: Put one Current_User registry key under the mentioned component and set that registry key as the keypath

Resolve ICE57 Errors

Error: Component has both per user and per machine data with a per machine keypath

Solution: Create a new component (with a new GUID), move all of the per user data from the component that kicks up the error to the new one. Set one of the files/reg keys as it’s keypath.