CODEWITHSUNDEEP
windows-installerinstallshield-2012orca
user2344093
user2344093

Reputation: 31

MSI Validation returns "ICE81 Failure ICE Internal Error 1867. API Returned: 1615."

All of my MSI installations display the same ICE81 "failure" during validation but I can't figure out what is causing it. It happens no matter which MSI editor I use to run the validation (MS Orca, Flexera InstallShield, InstEdit.com). All my installation packages use external CAB files located in the correct place (same folder as MSI file) and all CAB files are signed with the same digital signature the MSI file is signed with (and all the records in the Media, MsiDigitalCertificate, MsiDigitalSignature, and MsiPatchCertificate tables appear to be correctly authored).

ICE81 Failure ICE Internal Error 1867. API Returned: 1615.     MSIEditor_full_path\darice.cub
ICE81 Failure Error 2228: C:\Users\my_user_name\AppData\Local\Temp\random_tmp_filename.tmp, feature_name, SELECT `DiskId`, `Cabinet` FROM `Media` WHERE (`DiskId` = cab_name.cab)     MSIEditor\darice.cub

Any ideas?

Upvotes: 3

Views: 455

Answers (2)

Colby Ringeisen
Colby Ringeisen

Reputation: 1

I have had this problem with our MSI packages for YEARS. I have the same setup: all packages use external CAB files located in the correct place and signed with the same digital signature used to sign the MSI package. We use InstallShield to build the packages (started with IS Developer 2010, upgraded several times along the way, and now currently using IS Premier 2020). All builds have always used darice.cub to do validation (which I believe ultimately comes from Microsoft).

What I have observed is that this behavior goes away if I DROP the 3 digital signature tables from the MSI package (MsiDigitalCertificate, MsiDigitalSignature, and MsiPatchCertificate). Of course, these are required in order to release a signed package so deleting them really isn't an option. I just point out that if I do delete them and then run validation the failure notification (“ICE81 Failure ICE Internal Error 1867. API Returned: 1615.”) is no longer encountered.

In short, this may still be a problem with darice.cub but it's only a problem when the package is signed with a digital signature. That would lead me to believe it doesn't really have anything to do with the SQL statement being generated by the darice.cub ICE81 validation check but rather something to do with accessing tables when the package is signed.

Upvotes: 0

Rob Mensching
Rob Mensching

Reputation: 35806

The error is ERROR_BAD_QUERY_SYNTAX which means "The SQL query syntax is invalid or unsupported." So, the internal SQL query the ICE is making to validate your MSI is failing. Looking at the query the only part that can be failing is the query: WHERE DiskId=cab_name.cab.

Looking closer the issue is that cab_name.cab is a string which means it is supposed to be enclosed in single quotes. In other words, it should look like: 'cab_name.cab'. So why didn't the ICE correctly quote the string? Well, that is the answer.

The DiskId column of the Media table is supposed to be a number. Somehow cab_name.cab got inserted into the first column of the Media table where a number (like 1) is expected instead. The ICE doesn't put quotes around the DiskId because it's expecting a number and numbers are not supposed to be quoted.

To fix, change the DiskId (first) column of the Media table to a positive number (I like 1) and put the cab_name.cab value in the Cabinet (fourth) column.

I'm not sure what tools allowed you to put a string in an integer column but you might send them a bug since all sorts of things won't work. :)

Upvotes: 3

Related Questions