tools/jpackage/windows/Win8282351Test.java in jdk_tools_0 fails on most machines, passing on test-azure-win2012r2-x64-3

[smlambert]

tools/jpackage/windows/Win8282351Test.java (in jdk_tools target), fails in error on build-alibaba-win2012r2-x64-2, test-ibmcloud-win2012r2-x64-1, but passes on test-azure-win2012r2-x64-3:

ERROR: Expected [0]. Actual [1]: Check command [C:\Users\Jenkins\workspace\Test_openjdk17_hs_extended.openjdk_x86-64_windows_testList_1\openjdkbinary\j2sdk-image\bin\jpackage.exe --dest .\test\output --name Win8282351Test$-$$-$$$ --type msi --app-image .\test\appimage\Win8282351Test --win-menu --win-shortcut --verbose](12) exited with 0 code
[10:20:12.777] [  FAILED  ] Win8282351Test.test; checks=4

• test suite/name (e.g, BUILD_LIST, TARGET, CUSTOM_TARGET)?
• a link into recent Test_ job on https://ci.adoptopenjdk.net which showed the failure
• Hyperlink to re-run in Grinder:
• Is there an existing issue elsewhere covering this?
• Which machine(s) does it work on? test-azure-win2012r2-x64-3 (see Grinder 6319 for success run), not sure what version of WiX toolkit is present on this machine.
• Which machine(s) does it fail on? Most. deep history shows failing on build-alibaba-win2012r2-x64-2, test-ibmcloud-win2012r2-x64-1, build-ibmcloud-win2012r2-x64-2, build-azure-win2012r2-x64-2 WiX 3.14.0.3910 detected
• mentioned in AQAvit Triage for Dry Run release-openjdk17-pipeline (Jan 2023 release prep) aqa-tests#4240 (comment)

---

Test Info
Test Name: jdk_tools_0
Test Duration: 17 min 38 sec
Machine: build-alibaba-win2012r2-x64-2
TRSS link for the test output: https://trss.adoptium.net/output/test?id=63c219e9ed0b30773ba354a9

Build Info
Build Name: Test_openjdk17_hs_extended.openjdk_x86-64_windows_testList_1
Jenkins Build start time: Jan 13 2023, 06:26 pm
Jenkins Build URL: https://ci.adoptopenjdk.net/job/Test_openjdk17_hs_extended.openjdk_x86-64_windows_testList_1/76/
TRSS link for the build: https://trss.adoptium.net/allTestsInfo?buildId=63c218eaed0b30773ba34d89

Java Version
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+8 (build 17.0.6+8)
OpenJDK 64-Bit Server VM Temurin-17.0.6+8 (build 17.0.6+8, mixed mode, sharing)

This test has been failed 2 times since Jan 12 2023, 06:16 am
Java Version when the issue first seen
openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment Temurin-17.0.6+8 (build 17.0.6+8)
OpenJDK 64-Bit Server VM Temurin-17.0.6+8 (build 17.0.6+8, mixed mode, sharing)
Jenkins Build URL: https://ci.adoptopenjdk.net/job/Test_openjdk17_hs_extended.openjdk_x86-64_windows_testList_1/75/

The test failed on machine build-alibaba-win2012r2-x64-2 1 times
The test failed on machine test-ibmcloud-win2012r2-x64-1 1 times

Rerun in Grinder

[Haroon-Khel]

Rerunning

build-alibaba-win2012r2-x64-2 https://ci.adoptopenjdk.net/job/Grinder/6358/console
test-ibmcloud-win2012r2-x64-1 https://ci.adoptopenjdk.net/job/Grinder/6359/console
test-azure-win2012r2-x64-3 https://ci.adoptopenjdk.net/job/Grinder/6360/console

[Haroon-Khel]

Passes on test-azure only. I'll take test-ibmcloud-win2012r2-x64-1 offline, but keep build-alibaba-win2012r2-x64-2 online as its a build machine with no test label

[sophia-guo]

a few other tests got the same issue only pass on test-azure-win2012r2-x64-3

javax/net/ssl/SSLSocket/Tls13PacketSize.java.Tls13PacketSizetools/jpackage/share/PerUserCfgTest.java.PerUserCfgTest
tools/jpackage/share/ServiceTest.java.ServiceTest
tools/jpackage/windows/Win8282351Test.java.Win8282351Test
tools/jpackage/windows/WinLongVersionTest.java#id1.WinLongVersionTest_id1

[smlambert]

Since test-azure-win2012r2-x64-* machines have been replaced with test-azure-win2022-x64-* machines, we do not have any machines where this jdk_tools testcase can pass.

Check configuration of WIX Toolset on existing test machines as to why...

    C:\Program Files (x86)\WiX Toolset v3.14\bin\light.exe -nologo -spdb -ext WixUtilExtension -out D:\jenkins\workspace\Grinder\aqa-tests\TKG\output_1705172566315\jdk_custom_0\work\scratch\0\.\test\output\Win8282351Test$-$$-$$$-1.0.msi -sice:ICE27 -loc C:\Users\jenkins\AppData\Local\Temp\jdk.jpackage7670213496896116375\config\MsiInstallerStrings_en.wxl -cultures:en-us C:\Users\jenkins\AppData\Local\Temp\jdk.jpackage7670213496896116375\wixobj\main.wixobj C:\Users\jenkins\AppData\Local\Temp\jdk.jpackage7670213496896116375\wixobj\bundle.wixobj C:\Users\jenkins\AppData\Local\Temp\jdk.jpackage7670213496896116375\wixobj\uui.wixobj
[19:05:05.526] Output:
    light.exe : error LGHT0217 : Error executing ICE action 'ICE01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0217 : Error executing ICE action 'ICE02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0217 : Error executing ICE action 'ICE03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0217 : Error executing ICE action 'ICE04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0217 : Error executing ICE action 'ICE05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0217 : Error executing ICE action 'ICE06'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0217 : Error executing ICE action 'ICE07'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wixtoolset.org/documentation/error217/ for details and how to solve this problem. The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".
    light.exe : error LGHT0216 : An unexpected Win32 exception with error code 0x643 occurred: Action - 'ICE09' Fatal error during installation
[19:05:05.526] Returned: 216

adoptium/aqa-tests#4960 (comment)

[smlambert]

@steelhead31 - could this be a similar issue to what you have seen where 'stuff' as a service on Windows machines has weird characters in the path? I am noting the error msg (see #2885 (comment)) that reads: The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".

[steelhead31]

@steelhead31 - could this be a similar issue to what you have seen where 'stuff' as a service on Windows machines has weird characters in the path? I am noting the error msg (see #2885 (comment)) that reads: The following string format was not expected by the external UI message logger: "The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.".

@smlambert its possible, but I think there are a couple of more likely culprits related to windows configuration / group policy settings, the later versions of windows lock down the windows installer service quite a lot, and some of the azure windows images have quite locked down permissions, if you'd like I can break this out into a separate issue, and I can investigate further?... It'd be handy if somebody could give me some pointers on the aqa targets required for me to be able to test this on a command line though!

[smlambert]

re: #2885 (comment)

in Jenkins, TARGET=jdk_tools

Steps to run from scratch on outside of Jenkins / on commandline (presumes you have a Temurin JDK downloaded onto the machine into /jdkDir replace with actual location of your JDK that you want to test):

git clone https://github.com/adoptium/aqa-tests.git
cd aqa-tests
export TEST_JDK_HOME=/jdkDir
export BUILD_LIST=openjdk
export CUSTOM_TARGET=tools/jpackage/windows/Win8282351Test.java 
./get.sh
cd TKG
make compile
make _jdk_custom

For a more complete run of all testcases in the jdk_tools target, not just Win8282351Test, you could change the last line to:

make _jdk_tools

[steelhead31]

Test passed on win2022 machine 3 .

# AQACert.log content: 
# 
# Hostname: test-azure-win-2
#SHA.txt content: 
# 
# Timestamp: Tue Feb 13 11:42:48 2024 UTC 
# CUSTOM_TARGET: tools/jpackage/windows/Win8282351Test.java
# RESULTS_SUMMARY: TOTAL: 1 EXECUTED: 1 PASSED: 1 FAILED: 0 DISABLED: 0 SKIPPED: 0
1..1
ok 1 - jdk_custom_0
 ---
   duration_ms: 171050
 ...

[steelhead31]

Specific test, does pass as both adoptopenjdk and jenkins user on all 3 test-azure-win2022-x64-x machines, testing all tools tests... testing with jdk17.0.9+9.1

[steelhead31]

I've managed to replicate the error via grinder on one machine https://ci.adoptium.net/job/Grinder/8812/console , despite it passing locally.. so it definitely seems machine specific

[steelhead31]

Works ok via cli & jenkins on test-azure-win2022-x64-3 , works via cli on test-azure-win2022-x64-1 & test-azure-win2022-x64-2, however fails via grinder on both test-azure-win2022-x64-1 & test-azure-win2022-x64-2.. investigating further, suspect its a windows oddity.... as all 3 machines were built from the same playbooks.

[steelhead31]

This is now working on all 3 machines..  ( machine 1: https://ci.adoptium.net/job/Grinder/8826/console , machine 2 : https://ci.adoptium.net/job/Grinder/8827/console & machine 3 : https://ci.adoptium.net/job/Grinder/8825/console ).. .Thanks muchly!

[steelhead31]

I believe this to be the same root cause as the WSL detection issue, in that the PATH environment variable was being corrupted by the windows service wrapper used to run jenkins as a service, these machines were switched to using a CLI startup, and I believe this is the reason the tests now pass.

[karianna]

@steelhead31 So we can close this?

[steelhead31]

@karianna yes, I was just waiting on a final confirmation, but it all looks good now.