Installscript custom action under 64 bits DONT RUN

[Luis_Roux]

Hello Everybody,

I guess nobody is really using IS2008 to create installers using installscript custom actions under Windows 64 Bits (2003 & Vista). I have tried for weeks to run a installscript CA under 64 Bits with no luck, while the same CAs run under 32 Bits flawlessly.

I have attached to this message a very simple IS2008 Basic MSI Project. It has the following relevant properties:
- Summary Information Stream -> Require Administrative Privileges: Yes.
- Releases -> SINGLE_EXE_IMAGE -> Setup.exe -> Required Execution Level: Administrator.
- The following installscript custom action is schedulled in the UI sequence after AppSearch:

function MyFunction(hMSI)
// To Do: Declare local variables.
begin
if (ExistsDir(WINDIR) = EXISTS) then
SprintfBox(INFORMATION, "MyTest", "%s exists.", WINDIR);
else
SprintfBox(INFORMATION, "MyTest", "%s does not exist", WINDIR);
endif;
LaunchApp(WINDIR ^ "NOTEPAD.EXE", "");
end;

1) Under XP, 2003 & Vista 32 bits it opens the Dialog and Launches the notepad.
2) Under 2003 & Vista 64 bits it does nothing. No dialog is shown, no notepad is run.

I don't like the idea of rewriting my CAs on VBScript or C, so don't even suggest it. If that is the only solution, I ratter rewrite my installers in a new tool.
I don't like the idea of moving away from InstallShield, but if InstallShield don't run installscript CAs under 64 Bits, I may have no choice.

Since I have wasted so much time with this problem and I may overlooked something obvious. Could somebody comfirm me that install CAs runs under 64 Bits Windows (2003 or Vista)? Could somebody provide me a very simple project that shows that installscript CAs actually work under Windows 64 Bits (2003 or Vista)?

Thank you very much,

Luis Roux
lroux_AT_bitam.com

[MichaelU]

I had no problems creating a Basic MSI project, adding a setup.rul, adding

SprintfBox(INFORMATION, "Test", "Running on 64 bits: %d...", SYSINFO.bIsWow64);
abort;

to the predeclared MyFunction(hMSI), adding InstallScript custom action "TestOn64", calling MyFunction after SetupInitialization with condition "Not Installed". I built and ran this install.

I saw a message box with string "Running on 64 bits: 1". Do these steps fail for you?

[Luis_Roux]

Thank you for you response Michael.

I just try what you suggest and it is not showing the Dialog under Windows Vista 64, and it is not aborting the installation. Under Windows XP SP2 32 Bits, it is showing the dialog and aborting the installation.

I'm using InstallShield 2008 under Windows XP SP2, then I'm moving the generated setup.exe to a Windows Vista 64 (Build 6000). Any ideas what could be wrong with my environment?

[MRKiscaden]

I recently ran into a similar problem. This may not apply to you, but it would be worth looking into.

If you generate a verbose log of your installer. check to see if you have a "Script function Failure" message in the log.

InstallShield 12:09:57: Detected X64 OS
InstallShield 12:09:57: Extracting support file ISBEWX64.exe to C:\Users\MRK\AppData\Local\Temp\{E6AE7CBF-BE74-43B6-BDB6-5F57E013FED2}\ISBEW64.exe
InstallShield 12:09:57: Setting script cmdline...
InstallShield 12:09:57: ProductCode is {3662EAA9-69C2-4026-BE7F-5EBB694A86DA}
InstallShield 12:09:57: Initializing Engine
InstallShield 12:09:58: Script function f9 failure. Unknown Exception.

I build all of my projects using the Automation Interface via a Perl script. By changing my perl script from using the line Win32::OLE->new("SAAuto14.ISWiProject") to the line Win32::OLE->new("ISWiAuto14.ISWiProject") the problem went away. What this does is switch my builder from using the StandAlone builder to the one built into InstallShield 2008.

So if you are using the Stand Alone Installer, try doing the build from within the user interface.

[Luis_Roux]

Thank you very much to everybody. I have moved IS2008 from my XP to a Vista 64, and I have rebuilt my project under 64 Bits and the resulting setup.exe is able to run the CAs. Apparently is not the same if you built under 32 bits and them move to 64 Bits than the other way around. Any way now my CAs are working and I'm happy. 😄

[MichaelU]

Interesting. I wasn't personally aware of that requirement, but I did indeed build and execute on a single 64-bit machine.

[DLee65]

I am encountering the same problem, however, I believe this is related to the configuration of the Standalone build on the build server.

The reason I believe this is that I had this working using the same perl script and command line interface previously, but our build machine had a catastrophic hardware failure and we had to transfer the builds to a different server. Since then the InstallScript custom actions have not worked correctly on 64bit operating systems. Neither build machine has a 64bit OS or processor.

However, I am seeing the same MSI log results that MRKiscaden reported below, indicating that the script engine could not be loaded.

I will continue to look into this. If anyone has any other insights or knowledge of file dependencies that I should be looking for, that would be appreciated.

Thanks.

[joshstechnij]

Are you receiving any errors/warnings about not being able to stream ISBEW64.exe during your builds?

Also, if you can reproduce this with a sample project, would it be possible for you to attach the sample?

[DLee65]

joshstechnij wrote:
Are you receiving any errors/warnings about not being able to stream ISBEW64.exe during your builds?

Also, if you can reproduce this with a sample project, would it be possible for you to attach the sample?

I did a search of the latest build and ISBEW64 does not appear in the build output log at all.

Making a sample project and getting it integrated into our build process would be rather time consuming and I don't think that the Build Managers would approve this. This has to build against the stand alone build to fail. Like I said, things were working correctly prior to having to move the build to another machine. I am testing this theory now.

[DLee65]

I just finished a build on my development machine using the standalone build (of course full IDE is still installed too, so it is not the same) and using the same scripts that run on the build machines and the InstallScript engine loads correctly.

I tried another product that is built on a different server and that uses the same script to build the product but with different parameters passed in, and that product installed correctly to my test machine.

Therefore I am left to conclude that there is a problem in the configuration of the Standalone build setup for IS2008 on the machine currently handling this project.

[joshstechnij]

I tried building a sample project with IS 2008 and the IS 2008 standalone build and I could not reproduce any issues when running the built packages on 64-bit machines.

Based on the previously posted log information, my guess is there is some issue occurring during textsub initialization in the engine (it's the only 64-bit code that the engine runs during initialization) which is related to the ISBEW64.exe files. Since the build always streams IA64 and x64 versions of these files in for InstallScript custom actions (it does not act any different on a 32-bit or 64-bit machine), a build warning or error should be logged if there was an issue when attempting to stream them onto ISSetup.dll. Unfortunately, with the information available, I don't have any specific reasons why this behavior is occurring.

[DLee65]

I am going to look at our setup process for build machines and see if we are missing anything. I will install the IS2008 standalone build and then compare it to my machine and see if I can see anything missing. Perhaps that will help.

[groupjm]

We do have the identical problem on a Windows 2003 Server x6. All InstallScript functions fail to execute on this machine, the log contains multiple lines reporting
"Script function f failure. Unknown Exception."
All of our setups are built on a build machine (Windows 2003 Server 32bit) running InstallShield Standalone Build.
So, did you find a solution/workaround for this behaviour?