cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
tcom36
Level 7

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
Labels (1)
0 Kudos
(12) Replies
tcom36
Level 7

I searched for 1603 in the log file and found the following lines:

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?
0 Kudos
tcom36
Level 7

As strange as it sounds, when the older application is installed by choosing german as installation language, the update works without any problem.

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?
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

I'm not sure the "Unable to delete file" error is related to the root problem, since this is just the MSI engine shutting down and attempting to clean up. Can you attach the log file where this 1603 error occurs?
0 Kudos
tcom36
Level 7

Well, here is an extract of the log, I hope it helps:

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?
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

I'm not sure why this problem occurs specifically when selecting French as the install language. Unfortunately, the log information present doesn't contain any indications of where the failure is occurring or why.

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
0 Kudos
Peter_Kosenko
Level 7

So, has anyone figured this out?

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.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

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.
0 Kudos
Peter_Kosenko
Level 7

Thank. Yes, I read the help file and understand the use of the ISAlias table. None exists in my project because it has been a LONG time since we have converted anything from those older versions of InstallShield. As far as I could tell, there were no problems with the names of any features or components.

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.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

Whether the project is hanging or aborting at this particular point in a log, the troubleshooting steps will be basically the same. The behavior you are seeing needs to be isolated before further action can be taken:
- 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.
0 Kudos
Peter_Kosenko
Level 7

I noticed something else I need to check out, since we use VerGetFileVersion().

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.
0 Kudos
joshstechnij
Level 10 Flexeran
Level 10 Flexeran

The VerGetFileVersion function is mostly a wrapper around the Windows version information APIs. Unless these APIs have an issue on Windows Vista, I'm not certain why any hangs may be occurring while calling this function. Are you able to reproduce this behavior with a sample project on Vista?
0 Kudos
Peter_Kosenko
Level 7

It turned out that the issue was NOT the file version function.

This was a complex client-server installation. We were installing the client side, which checks the version of the server application during upgrade by grabbing the server path from the registry (where we put it on initial installation).

When the user updates the Client side, we check that the Admin has updated the server component of the application before proceeding.

The upgrade installer grabs the path using RegLocator and AppSearch tables and saves it to a property. The script grabs the property using MsiGetProperty. BUT, the Buffer for MsiGetProperty was not reset and the path retrieved was getting truncated. Hence the server component could not be found and the version could not be retrieved. We reset the buffer value to something longer and we added a little more checking for return of the version number.

Since the Installscript was running asynchronously, without writing to the Msi Log at that point, we were getting other information than the error source in the verbose log, which was confusing me (it seemed to be hanging at the ISAlias table, but that was not the issue).

I guess the lesson here is to remember to reset the nBuffer property to an appropriate value EVERY TIME you use the MsiGetProperty function, or you may be getting a short buffer from the previous function call.
0 Kudos