dominique.schrecklin1.552494444672522E12 asked a question.
Error 1603 during update in InstallScript MSI
I have a version of a software installed, when calling the setup the InstallScript MSI project for a newer version, Installshields asks if I wish to update the software. If I click on yes, it runs a while, but I am getting a fatal error 1603 during the update.
I tried to activate the logging when updating, and the last entries in the log are:
...
End of action : CostFinalize. Returned value : 1
MSI (c) (DC:1C) [time]: Note 1: 2205 2: 3: ISAlias
MSI (c) (DC:1C) [time]: Note 1: 2205 2: 3: ISAlias 4: SELECT * FROM ISAlias
InstallShield : Installation aborts, ready to shut down.
InstallShield : Invoking __ResetMsiObject...
Any hint where I could get more information? Are there any information I can get in the log which might hint me to the problem?
I had a look about the error 1603, but I can find no reason. I have admin rights, disk space is enough, reboot does not solve the problem.
The new version is expected to replace most of the binaries by the newer version, and a few files have been added to a component.
MSI (s) (18:E8) [14:55:53:921]: Attempting to delete file C:\WINDOWS\Installer\1178ca3.mst
MSI (s) (18:E8) [14:55:53:921]: Unable to delete the file. LastError = 32
MSI (s) (18:E8) [14:55:53:937]: Cleaning up uninstalled install packages, if any exist
MSI (s) (18:E8) [14:55:53:937]: MainEngineThread is returning 1603
MSI (s) (18:54) [14:55:53:937]: Destroying RemoteAPI object.
MSI (s) (18:10) [14:55:53:937]: Custom Action Manager thread ending.
=== Fin de l'écriture dans le journal : 09.05.2008 14:55:53 ===
MSI (c) (94:BC) [14:55:53:937]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (94:BC) [14:55:53:937]: MainEngineThread is returning 1603
=== Verbose logging stopped: 09.05.2008 14:55:53 ===
When calling the setup.exe, I am on an account with administrator rights (and I have the rights to delete this mst file by hand).
Under InstallShield, in the Releases/PROJECT_ASSISTENT/SINGLE_EXE_IMAGE I set under Setup.exe/Required Execution Level to Highest available.
Any hints?
When choosing french as the installation language of the older application, the update fails with this 1603 error, as stated above.
The logfile contains some "Transformation Table error." entries, but I have no clue what fails.
How can it be the update is dependent on the language? Where can I look to find the problem?
MSI (s) (14:2C) [13:20:42:843]: Validating transform 'C:\WINDOWS\Installer\1372677.mst' with validation bits 0
MSI (s) (14:2C) [13:20:42:843]: Transform 'C:\WINDOWS\Installer\1372677.mst' is valid.
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: Patch 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2205 2: 3: PatchPackage
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: Media 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: File 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: TRANSFORM: 'PatchPackage' table is missing or empty. No pre-transform fixup necessary.
MSI (s) (14:2C) [13:20:42:843]: TRANSFORM: Applying regular transform to database.
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: _Tables 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: _Columns 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: AdminExecuteSequence 3: -2147287038
MSI (s) (14:2C) [13:20:42:843]: Note: 1: 2262 2: Condition 3: -2147287038
...
Property(S): IS_SQLSERVER_DIALOG = 1
Property(S): ARPNOMODIFY = 1
Property(S): ADDLOCAL = ExcelPlugin
Property(S): ProductLanguage = 1036
MSI (s) (14:2C) [13:20:46:890]: Note: 1: 1729
MSI (s) (14:2C) [13:20:46:890]: Transforming table Error.
MSI (s) (14:2C) [13:20:46:906]: Transforming table Error.
MSI (s) (14:2C) [13:20:46:906]: Produit : emotachdirect -- Echec de la configuration.
MSI (s) (14:2C) [13:20:46:906]: Attempting to delete file C:\WINDOWS\Installer\1372677.mst
MSI (s) (14:2C) [13:20:46:906]: Unable to delete the file. LastError = 32
MSI (s) (14:2C) [13:20:46:906]: Cleaning up uninstalled install packages, if any exist
MSI (s) (14:2C) [13:20:46:906]: MainEngineThread is returning 1603
MSI (s) (14:6C) [13:20:46:906]: Destroying RemoteAPI object.
MSI (s) (14:C4) [13:20:46:906]: Custom Action Manager thread ending.
=== Fin de l'écriture dans le journal : 13.05.2008 13:20:46 ===
MSI (c) (38:04) [13:20:46:906]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (38:04) [13:20:46:906]: MainEngineThread is returning 1603
=== Verbose logging stopped: 13.05.2008 13:20:46 ===
How does it come that I have this 1603 failure when the older application is installed with french as choosen installation language, but not when selecting german?
What is more likely is something is causing the script to abort:
[CODE]MSI (c) (DC:1C) [time]: Note 1: 2205 2: 3: ISAlias 4: SELECT * FROM ISAlias
InstallShield : Installation aborts, ready to shut down.
InstallShield : Invoking __ResetMsiObject...[/CODE]
Have you changed the OnResume event in your script? If so, can you add a MessageBox call to the beginning of the event to see if the OnResume event is actually running?
I have an InstallScript-MSI upgrade installer (InstallShield 2008) that hangs at the following point, but only on Vista?
This occurs AFTER feature selection during the upgrade process. The last feature is properly selected, then the upgrade goes haywire. So I don't think there is any problem with features (the features are the same, no additions, no name changes).
MSI (c) (F0:1C) [14:48:24:092]: Note: 1: 2228 2: 3: ISRequiredFeature 4: SELECT * FROM ISRequiredFeature WHERE RequiringFeature = 'PDFManuals'
MSI (c) (F0:1C) [14:48:24:292]: Note: 1: 2205 2: 3: ISAlias
MSI (c) (F0:1C) [14:48:24:292]: Note: 1: 2228 2: 3: ISAlias 4: SELECT * FROM ISAlias
There is NO ISAlias table in the compiled installer's .MSI because there is no "alias" information in the PROJECT's ISAlias table. So I can understand why a table error is getting tossed. The table being looked for is missing. What I DON'T understand is why the installer setup.exe is triggering a lookup of that table in the first place.
Querying the table, whether it is present or not, will not typically cause a project to abort. The existing log information in this thread showed projects aborting in unrelated script code. A script abort could be caused by an exception related to attempting to use a COM object that wasn't created or throwing an error, or some other user related script code issue. The location of the error can be isolated by including a default script in the project. If the issue still occurs, the issue is occurring in InstallScript runtime script code; if the issue no longer occurs, the issue is in user script code. If the issue does appear to be in the InstallScript runtime, we need to be able to reproduce the issue to determine what the cause could be.
The problem with my project is NOT that it is aborting. It is that it is hanging on Vista at the point where the query to the ISAlias table is being done. The installer just sits there without returning any sort of response. It does this on Vista.
The verbose log ends here:
MSI (c) (44:94) [12:56:19:278]: Note: 1: 2205 2: 3: ISAlias
MSI (c) (44:94) [12:56:19:278]: Note: 1: 2228 2: 3: ISAlias 4: SELECT * FROM ISAlias
Of course, that is no guarantee that the problem is there. It could be the NEXT thing (whatever that is), or something going on in some independent thread.
I actually tried importing an empty ISAlias table (using ORCA) in the compiled installer MSI, and I got another error number that told me nothing.
I (c) (A4:58) [14:24:43:507]: Note: 1: 2262 2: ISAlias 3: -2147287038
**************
" joshstechnij wrote:
The ISAlias table is used in projects that were converted from InstallScript to InstallScript MSI (in Developer 7/8) to allow for component, feature, directory keys to be able to contain invalid characters that are not allowed in MSI table keys. The InstallScript MSI runtime will always query this table to determine if any key aliases exist in the running project.
Querying the table, whether it is present or not, will not typically cause a project to abort. The existing log information in this thread showed projects aborting in unrelated script code. A script abort could be caused by an exception related to attempting to use a COM object that wasn't created or throwing an error, or some other user related script code issue. The location of the error can be isolated by including a default script in the project. If the issue still occurs, the issue is occurring in InstallScript runtime script code; if the issue no longer occurs, the issue is in user script code. If the issue does appear to be in the InstallScript runtime, we need to be able to reproduce the issue to determine what the cause could be. "
- Is this behavior occurring on all Vista machines (including ones with a clean install of Vista) or is it isolated to one or a couple of machines?
- Does a sample InstallScript MSI project with one feature, one component, one file, and a default setup.rul run on these machines?
- If a sample project works, does including a default setup.rul in your project change the behavior of the setup?
Note that regardless of whether a project was migrated from older versions on InstallShield or not, the InstallScript MSI runtime contains code to check for MSI key aliases in the ISAlias table. If none are present for features, components, setup types, or directories, the internal script code continues with the setup.
http://community.flexerasoftware.com/archive/index.php?t-177866.html
This would explain why there is a problem on VISTA ONLY.
The hang may be while checking the version number of an installed application on the server.