[Incident]: Some users report they are unable to access the case portal. Please see this community notice for more information.

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
sstrohmann
Level 2

Installation fails only if built with InstallShield Build module

I face a weird behaviour on a given machine when I install one’s of my installers.

When I build a Basic MSI project (with IsCmdBld.exe) on a machine installed with an InstallShield "full" version, the produced Setup works well on a given machine.

But when I build the same project (with the same version of IsCmdBld.exe) on a machine only installed with an InstallShield "Standalone Build module", the Setup doesn't work on the same given machine. In this case the install fails when the first CA is executed, in its step “Initializing Engine” :

InstallShield 10:32:04: Initializing Engine
MSI (c) (B0!E4) [10:32:04:329]: Closing MSIHANDLE (53) of type 790531 for thread 3044
CustomAction GetInstallFingerPrint returned actual error code 1603 but will be translated to success due to continue marking


The verbosed log file of this install is provided (file SET_4.1.0.0.log ).

The EventViewer reports an APPCRASH from MsiExec.exe :
Level Information, event 1001, Windows Error Reporting :

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: MsiExec.exe


The files “From_EventViewer.txt” and “Report.wer.txt” are provided.

So far, this installation failure has only happened on the given targeted machine described below :
Manufacturer : Advantech Co, Ltd.
Processor : Intel® Core ™ i7-2600, 4GB, 32-bit.
OS : Windows 7 Professional SP1.

InstallShield “full” version used :
InstallShield 2013 – Premier Edition with Virtualization Pack, Version 20, Service Pack 1


InstallShield "Standalone Build module" used :
InstallShield 2013 Standalone Build, Version 20

All hints and ideas will be welcome.
Labels (1)
0 Kudos
2 Replies
DLee65
Level 13

I do not know if this relates to your system, but one of the biggest differences between a development machine and a build machine utilizing the Standalone build system, is prerequisites.

On your development machine there is a clever little UI that allows you to download the required files for distributing a particular prerequisite. So one of the first things I would do is determine if you have all the required prerequisites and that they exist in the directory that the .PRQ files expect.

For me, I end up adding any required files to source control and then set the alternate prerequisite directory on the command line. The same goes for merge modules as well. It allows me to easily ensure that my system will build on any given build machine.
0 Kudos
sstrohmann
Level 2

DLee65 wrote:
I do not know if this relates to your system, but one of the biggest differences between a development machine and a build machine utilizing the Standalone build system, is prerequisites.

On your development machine there is a clever little UI that allows you to download the required files for distributing a particular prerequisite. So one of the first things I would do is determine if you have all the required prerequisites and that they exist in the directory that the .PRQ files expect.

For me, I end up adding any required files to source control and then set the alternate prerequisite directory on the command line. The same goes for merge modules as well. It allows me to easily ensure that my system will build on any given build machine.



Hi Dan,

Thanks for the given time on my issue and for the warning about management of PRQ with Standalone Build module.
Unfortunately, it's not the cause of my trouble in this case.
To be sure, I have just (re)tested my setup (built with Standalone Build module) on a different machine, and the installation worked without a problem; all PRQs and my Product are well installed.

So far, all my installers have been built with a Standalone Build module and deployed on a wide spectrum of different machines without triggering this particular failure.

I suspect that this problem is rather due to a peculiarity of the Advantech's machine than due to an InstallShield's problem.

Regards
Serge Strohmann
0 Kudos