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

installing fail on Windows 10

Hi there!

I am trying to install IBM SDK Node.js on Windows 10 (ibm-6.7.0.0-node-v6.7.0-win-x64.exe). The package contains InstallAnywhere 2014. I have installed JRE 1.7.079 and the file was set to compatible mode windows 7 and run admin. Lanch this error:

Flexeraax2$aaa: Windows DLL failed to load
at Flexeraax2.af(Unknown Source)
at Flexeraax2.aa(Unknown Source)
at com.zerog.ia.installer.LifeCycleManager.init(Unknown Source)
at com.zerog.ia.installer.LifeCycleManager.executeApplication(Unknown Source)
at com.zerog.ia.installer.Main.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)
Labels (1)
0 Kudos
(1) Reply
gireeshpunathil
Level 2

I was debugging the same issue, and have these observations and inference:

My versions:

LAX Version = 16.5
InstallAnywhere 2014 SP1
Version: 16.5

Error message with the culprit dll exposed:

Loading windoze dll: C:\foo\Windows\resource\iawin32.dll
Flexeraax2$aaa: Windows DLL failed to load
at Flexeraax2.af(Unknown Source)
at Flexeraax2.aa(Unknown Source)
at com.zerog.ia.installer.LifeCycleManager.init(Unknown Source)
at com.zerog.ia.installer.LifeCycleManager.executeApplication(Unknown Source)
at com.zerog.ia.installer.Main.main(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.zerog.lax.LAX.launch(Unknown Source)
at com.zerog.lax.LAX.main(Unknown Source)

While my node installer, Java, and the OS all are 64 bit, attempt to load a 32 bit dll is indeed the inflection point.

If you 'unzip' the installer, you will see 3 dlls in the Windows\resource folder of the extraction as:

2017-04-04 01:44 PM 109,912 iawin32.dll
2017-04-04 01:44 PM 310,104 iawin64.dll
2017-04-04 01:44 PM 132,440 iawin64_x64.dll

Evidently, iawin64.dll is the desired one, while the wrong one being picked up.
Obviously, if you swap the 32 and 64 bit ones and manually invoke the installer (Windows\Installer.exe), the installation succeeds. [ workaround #1 ]

Digging further to see which Java versions are affected and why this is happening, I tried this below code in a number of Java version / vendor combination, aftere each of the 'java' executbale made compatible with Windows 7.

C:\foo>cat OSN.java
public class OSN {
public static void main(String args[]) {
System.out.println(System.getProperty("os.name"));
}
}

C:\foo>java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build pwa6480sr3-20160428_01(SR3))
IBM J9 VM (build 2.8, JRE 1.8.0 Windows 7 amd64-64 Compressed References 20160427_301573 (JIT enabled, AOT enabled)
J9VM - R28_Java8_SR3_20160427_1620_B301573
JIT - tr.r14.java.green_20160329_114288
GC - R28_Java8_SR3_20160427_1620_B301573_CMPRSS
J9CL - 20160427_301573)
JCL - 20160421_01 based on Oracle jdk8u91-b14

C:\foo>java OSN
Windows 7

C:\foo>..\java7\bin\java -version
java version "1.7.0_80"
Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)

C:\foo>..\java7\bin\java OSN
Windows 7

C:\foo>..\java8\jdk1.8.0\bin\java -version
java version "1.8.0"
Java(TM) SE Runtime Environment (build 1.8.0-b132)
Java HotSpot(TM) 64-Bit Server VM (build 25.0-b70, mixed mode)

C:\foo>..\java8\jdk1.8.0\bin\java OSN
Windows 7

C:\foo>..\java8_u51\bin\java -version
java version "1.8.0_51"
Java(TM) SE Runtime Environment (build 1.8.0_51-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.51-b03, mixed mode)

C:\foo>..\java8_u51\bin\java OSN
Windows 7

C:\foo>"C:\Program Files\Java\jre1.8.0_131\bin\java.exe" -version
java version "1.8.0_131"
Java(TM) SE Runtime Environment (build 1.8.0_131-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.131-b11, mixed mode)

C:\foo>"C:\Program Files\Java\jre1.8.0_131\bin\java.exe" OSN
Windows 10


Interestingly, the Oracle Java 8 version does not turn os.name property into Windows 7 when run in the compatibility mode, with compatibility affinity with Windows 7.

Because of this the installer wasn't able to detect a valid win32 platform for the host, leading to picking up a default library, which happened to be a 32 bit one, and hence the failure.

For that matter, a 32 bit Java can be used to successfully drive the installer [ workaround #2 ]

If we enforce the os.name property to be 'Windows 7' while the installer is in progress, the issue can be circumvented easily, but the side effect of this change needs to be ratified all across the source lines, as we don't know which part of application(s) would be made hard-coded assumptions about the value of this property.

Control panel -> Edit environment variables -> Add new user defined property and add this key and value:
JAVA_TOOL_OPTIONS
"-Dos.name=Windows 7"

And then run the installer as usual - double click on the explorer window [ workaround #3 ] - remember to remove this environment variable, as it is pervasive and can have side effects.

Alternatively, open a command prompt, and set this environment variable for Java:
SET JAVA_TOOL_OPTIONS="-Dos.name=Windows 7"

And then run the installer on this prompt. [ workaround #4, also recommended ]
0 Kudos