If you are willing to do this then you better know what you are doing. There are errors, warnings and information messages. First, don't bother with the the warnings and info messages. Here are some hints (and I do stress hints) as to what to do with specific ICE error messages. If you go into my tutorial you'll see that some ICE errors can disappear by fixing other ICE errors. With practise, you'll be able to feel-your-way to resolve most if not all ICE errors.
The SDK also hints how to fix these ICE errors. Just click the SDK icon and search like this: ICE38
not: ICE 38
(Taken from Wise newsgroups)
> Registry: 'primarykey' cannot be the key registry key for
> Component: 'PerMachine'. The RegKey belongs to
> Component: 'notes.exe' http://dartools/iceman/ice02.html
> Component KeyPath PerMachine
> Evaluation: ICE02
To fix this, go to the Setup Editor page and the Components tab. Browse down to the component named "PerMachine" (which might even be highlighted in red) and right-click, choose "Details". Under the "Key Path Type:" drop-down, choose "File Key Path", and then choose any file from the "File Key Path:" drop-down just below it.
> The directory Lotus_Applications is in the user profile but is not listed in the RemoveFile table.
> http://dartools/iceman/ice64.html Directory Directory
> Evaluation: ICE64
This one is simply what it says... During the install, the "Lotus Applications" folder is created in the Start Menu. If you want to delete it during the Uninstall, add it to the RemoveFile table. (Follow the examples in the RemoveFile table and the directions in the MSI Help.)
ICE33 warnings are next to impossible to fix. The warning message hints to use the ProgId and Class tables. Discussing with other peers reveals that any attempt to fix ICE33 warnings are futile and will break the package.
For John_McFadyen, ICE33 warnings are not so impossible to fix:
When you have an ICE33 error, you can find the relevant inprocsvr32 key for that error. Then trace it back to the DLL which owns the COM registration.
Remove the DLL from the package, register it on the local machine [using regsvr32] then import it back into the package. (in some cases you may wish to keep the component code) which is another step.
On import, Wise will correctly pick up the ProgId/Class details. You may be required to select rescan COM data from the components view and you will find Wise correctly allocates the COM tables. The [ICE Error causing] registry data can then be safely removed.
ICE38 states that any component that installs to the user profile must have a registry key as its KeyPath. You have 2 ways to fix this:
-Create a bogus entries in registry in the HKCU and make them part of the component causing the error.
-Steal (aka move) a HKCU entry in registry from the CurrentUser component to the component causing the error.
Look in the Tutorial in the Fixing ICE errors section for more details on how to do the stealing method. For a straight answer ignore the greyed out sections in the tutorial.
An ICE57 error means that a component has both User (hive entries or profile files) and Machine (hive entries or files). That’s a no-no according to the MSI SDK (click ). You have to determine if the component is more of a User thing versus a Machine thing. (This is the feeling-your-way part I was talking about)
Usually, I break the stalemate by un-encoding the registry value. Look into the Tutorial in the Fixing ICE errors section for a hint on how to resolve this one.
ICE64 errors are directories in the user profile that will not be removed correctly (read “at all”)during uninstall or roaming user scenarios. To fix this you usually create a row for each folder in the RemoveFile table. Look into the Tutorial in the Fixing ICE errors section for a hint on how to resolve this one.
ICE64 ERROR The directory iPass is in the user profile but is not listed in the RemoveFile table.
In this one package I got an ICE 64 error but the “offending” directory does not exist in the user profile. It's in the All Users profile.
Upon removing the package, however, the iPass folder does get removed from the All Users profile so this is purely a cosmetic issue. Here ORCA even helps me find which iPass directory we are talking about:
The RemoveFile table.
-FileKey is anything. It’s just an identifying label. Let’s go with dir1
-Component_ usually, is the component that created the iPass folder to begin with. No component seams to be explicitly creating the folder. And unlike the tutorial, this package has no CreateFolder component that I could use. So I'll used CurrentUser. (Don't try to create a bogus Component for this. I tried and it created another ICE Error.)
-FileName needs to be blank to specify a directory and not a file.
-DirProperty is for a property that contains the full path to the iPass folder. The SDK says that this must be a property in the Directory table. So let’s look it up.
Open the Directory table and sort on the Directory_Parent column:
By using the name in the Directory column (it has the key icon), it seems to be iPass ( NOTE: this is a coincidence. Noticed that there are 2 iPass directories mentioned in the DefaultDir column. One has a Directory_Parent ProgramMenuFolder and the other it's ProgramFilesFolder. ProgramFilesFolder means C:\Program Files so we know we know we want the other one.)
-InstallMode determines when the file is removed. A setting of 2 means to remove it at package removal time. (These details are in the SDK, click , search for RemoveFile)