Symantec AV ICE Error
Hi All,
On running Full MSI Validation Suite in Orca (v3.1.4000.1830) I have three remaining ICE Errors that I'd like to fix:
ICE03 Error Value Exceeds Max Value; Table: Custom Action; Column: Type; Keys(varies......)
I read and understand the error as the value of the number in the Type colum is too large; the three offending Type numbers are: 8193, 8243 and 11265.
I did some googling, visited MSDN, etc but can't seem to find any information on the values of these Custom Action Types: 8193 & 8243.
Custom action Type 11265 refers to hidden data/passwords/security which figures as this is an AV product with passwords.
Any ideas?
Brian
On running Full MSI Validation Suite in Orca (v3.1.4000.1830) I have three remaining ICE Errors that I'd like to fix:
ICE03 Error Value Exceeds Max Value; Table: Custom Action; Column: Type; Keys(varies......)
I read and understand the error as the value of the number in the Type colum is too large; the three offending Type numbers are: 8193, 8243 and 11265.
I did some googling, visited MSDN, etc but can't seem to find any information on the values of these Custom Action Types: 8193 & 8243.
Custom action Type 11265 refers to hidden data/passwords/security which figures as this is an AV product with passwords.
Any ideas?
Brian
0 Comments
[ + ] Show comments
Answers (10)
Please log in to answer
Posted by:
AngelD
15 years ago
Don't bother fixing vendor MSIs, if they work they work!
However, the Type column is a combination of the type and options.
http://msdn.microsoft.com/en-us/library/aa372048(VS.85).aspx
If you use InstEd it will actually show you the different options which is part of the Type number(s).
However, the Type column is a combination of the type and options.
http://msdn.microsoft.com/en-us/library/aa372048(VS.85).aspx
If you use InstEd it will actually show you the different options which is part of the Type number(s).
Posted by:
fritoz
15 years ago
Don't bother fixing vendor MSIs, if they work they work!
Sorry, I disagree there. Most estates I've worked in have fixed ICE errors (even been one place where they wanted warnings fixed lol!) and the ones that haven't I've tended to fix them anyway as that was what I was used to as "best practice." I appreciate one person's best practice isn't anothers though.
Anecdotally I believed these estates to be more stable but that's probably just wishful thinking :o)
Thanks for the heads up for InstEd though.
Brian
Posted by:
AngelD
15 years ago
Hi Brian,
I think you will see most packagers do not fix vendor's MSI.
For repackaged ones yes, that is recommended.
But I must say it sounds strange that you get ICE03 on the CustomAction.Type column value.
Can you verify which schema the MSI is created with, could be for Windows Installer v4.x and in that case download Windows Installer 4.5 SDK which has a newer version of ORCA. You could also use InstEd for validation as it also includes the new CUB file for validation as the SDK does.
I think you will see most packagers do not fix vendor's MSI.
For repackaged ones yes, that is recommended.
But I must say it sounds strange that you get ICE03 on the CustomAction.Type column value.
Can you verify which schema the MSI is created with, could be for Windows Installer v4.x and in that case download Windows Installer 4.5 SDK which has a newer version of ORCA. You could also use InstEd for validation as it also includes the new CUB file for validation as the SDK does.
Posted by:
fritoz
15 years ago
Hi,
If I browse to the _Validation table the Max Value in there is 4095. Changing this value to a value higher than the largest CA Type solves the ICE03 Error.
However, this seems like a bot of tricksters fix. I validated in InstEd and used various validation sets and browsed to the installed CUB files but still get the error.
I'm downloading the 4.5 SDK out of curiosity. I'll document the three ICE Errors as an exception to our standards.
Thanks for the input.
Brian
If I browse to the _Validation table the Max Value in there is 4095. Changing this value to a value higher than the largest CA Type solves the ICE03 Error.
However, this seems like a bot of tricksters fix. I validated in InstEd and used various validation sets and browsed to the installed CUB files but still get the error.
I'm downloading the 4.5 SDK out of curiosity. I'll document the three ICE Errors as an exception to our standards.
Thanks for the input.
Brian
Posted by:
jmcfadyen
15 years ago
i also tend to steer clear of fixing vendor msi errors. often vendors do not follow strict windows installer based guidelines and fixing their ICE errors can actually introduce worse errors I have seen this on many occassions.
i think you will find a majority of the repackagers here tend to avoid this as well. in saying that I am all for fixing your own ICE errors.
i think you will find a majority of the repackagers here tend to avoid this as well. in saying that I am all for fixing your own ICE errors.
Posted by:
AngelD
15 years ago
Posted by:
fritoz
15 years ago
Thanks AngelD just doing my sums and subtracting the relevant flag bit value :o)
Perhaps I should clarify:
I fix all ICE errors in my MSIs and have taken this wherever I've gone. I've been fortunate enough to have worked in (and helped introduce where necessary) strict packaging and particulalry testing standards. In this circumstance we fix all ICE errors and if the package is signed off at UAT and pilot testing then the package goes as is. Should any package fail testing we have staged backups of the MST (or MSI in our own packages) taken after each ICE error fix up phase (e.g. after ICE03s, after ICE64s, etc) that we revert back to for a working package.
Maybe I should change, save myself some time and drop fixing ICE Errors in vendor MSIs.
I'd like to see the results of a poll on this, though from this post it appears I may well be in a minority of 1 lol!
Brian
edited for grammer
Perhaps I should clarify:
I fix all ICE errors in my MSIs and have taken this wherever I've gone. I've been fortunate enough to have worked in (and helped introduce where necessary) strict packaging and particulalry testing standards. In this circumstance we fix all ICE errors and if the package is signed off at UAT and pilot testing then the package goes as is. Should any package fail testing we have staged backups of the MST (or MSI in our own packages) taken after each ICE error fix up phase (e.g. after ICE03s, after ICE64s, etc) that we revert back to for a working package.
Maybe I should change, save myself some time and drop fixing ICE Errors in vendor MSIs.
I'd like to see the results of a poll on this, though from this post it appears I may well be in a minority of 1 lol!
Brian
edited for grammer
Posted by:
anonymous_9363
15 years ago
Now that I hav returned from my break, I'll wade in with "I almost never fix vendor MSI ICE errors, either."
I apply (within reason, obviously) the same view that I take when re-packaging, i.e that what I put out should, as far as is reasonably possible, replicate what the vendor's package does. As we know, vendors are cute at wriggling out of their support responsibilities and I have known some disown installs which have had transforms applied. I kid you not. As I say, I do take a pragmatic view about certain practises but in general, if their MSI fails validation, so be it.
I apply (within reason, obviously) the same view that I take when re-packaging, i.e that what I put out should, as far as is reasonably possible, replicate what the vendor's package does. As we know, vendors are cute at wriggling out of their support responsibilities and I have known some disown installs which have had transforms applied. I kid you not. As I say, I do take a pragmatic view about certain practises but in general, if their MSI fails validation, so be it.
Posted by:
LouisW
15 years ago
Posted by:
AngelD
15 years ago
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
so that the conversation will remain readable.