WindowsRegistry is not supported on this operating system.

[ncimino]

I'm hitting an exception, and I presume it is because of my companies anti-virus/malware software is blocking Gradle from reading the registry key \\HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\ProgramFilesDir. First thing to note is, I am working with my IT department to resolve this...

However, it doesn't seem like Gradle should stop the flow here. It could consult with the PATH environment variable to locate vswhere.exe as a workaround or even skip this step entirely and look for the tool-chains in PATH. Any of these would be infinitely better then just throwing an exception and stopping the flow with no way to disable or bypass it.

Here is the exception:

Caused by: org.gradle.internal.nativeintegration.NativeIntegrationUnavailableException: WindowsRegistry is not supported on this operating system.
    at org.gradle.internal.nativeintegration.services.NativeServices$BrokenService.invoke(NativeServices.java:345)
    at com.sun.proxy.$Proxy112.getStringValue(Unknown Source)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.version.DefaultVswhereVersionLocator.getVswhereInstall(DefaultVswhereVersionLocator.java:48)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.version.CommandLineToolVersionLocator.locateInstalls(CommandLineToolVersionLocator.java:56)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.version.AbstractVisualStudioVersionLocator.getVisualStudioInstalls(AbstractVisualStudioVersionLocator.java:32)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.DefaultVisualStudioLocator.locateInstallsWith(DefaultVisualStudioLocator.java:108)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.DefaultVisualStudioLocator.initializeVisualStudioInstalls(DefaultVisualStudioLocator.java:97)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.DefaultVisualStudioLocator.locateComponent(DefaultVisualStudioLocator.java:86)
    at org.gradle.nativeplatform.toolchain.internal.msvcpp.VisualCppToolChain.checkAvailable(VisualCppToolChain.java:175)

To locate the Visual Studios tools DefaultVswhereVersionLocator asks the registry for the Program Files or Program Files (x86) location and then appends Microsoft Visual Studio/Installer along with vswhere.exe. This action happens here:

    public File getVswhereInstall() {
        for (String programFilesKey : PROGRAM_FILES_KEYS) {
            File programFilesDir;
            try {
                programFilesDir = new File(windowsRegistry.getStringValue(WindowsRegistry.Key.HKEY_LOCAL_MACHINE, REGISTRY_PATH_WINDOWS, programFilesKey));
            } catch (MissingRegistryEntryException e) {
                // We'll get this when we try to look up "ProgramFilesDir (x86)" on a 32-bit OS
                continue;
            }

            File candidate = new File(programFilesDir, VISUAL_STUDIO_INSTALLER + "/" + VSWHERE_EXE);
            if (candidate.exists() && candidate.isFile()) {
                return candidate;
            }
        }

        return os.findInPath(VSWHERE_EXE);
    }

The exception is thrown at:

                programFilesDir = new File(windowsRegistry.getStringValue(WindowsRegistry.Key.HKEY_LOCAL_MACHINE, REGISTRY_PATH_WINDOWS, programFilesKey));

This windowsRegistry object is an instance of: net.rubygrapefruit.platform.WindowsRegistry

Perhaps one alternative would be to catch NativeIntegrationUnavailableException here.

The reason this is so problematic is it is one of the first things that happens in native tool-chain resolution. It is just initializing all of the tool-chains/install locations we haven't even got to where we select the tools yet. From the aforementioned stack-trace you can see this method ( in DefaultVisualStudioLocator):

    private void initializeVisualStudioInstalls() {
        if (!initialised) {
            locateInstallsWith(commandLineLocator);   // <--- We are here when this throws
            locateInstallsWith(windowsRegistryLocator);
            if (foundInstalls.isEmpty()) {
                locateInstallsWith(systemPathLocator);
            }

            initialised = true;
        }
    }

We are still in commandLineLocator as it is trying to use vswhere.exe to locate the tools. Even if that fails and windowsRegistryLocator I think it would make sense to continue on to systemPathLocator, but we cannot even get to where it would locate tools using the PATH which would at least let me workaround this issue.

If you have any ideas I'd love to hear them because I'm not able to run C++ builds on Windows right now.

[melix]

The very same error seems to happen when using Java Toolchains support and GitHub actions windows runners (runs-on: windows-2016).

[lacasseio]

I can confirm the same exception on GitHub actions windows runner:windows-latest (which is windows-2019). The error is a bit strange as the I'm able to run tests on Windows. However, I haven't tried on Windows 2019 due to not having access to such a machine.

[melix]

Any workaround for this problem? It currently blocks testing Windows builds on GitHub actions... I should mention that in my case it seems to happen with TestKit: the Gradle build which starts the tests actually works properly.

[ncimino]

We never did fix this, but I think you could easily create a extended class that wraps the windowsRegistry.getStringValue call with a catch for NativeIntegrationUnavailableException and if that fails then skip the registry code and move on to PATH resolution.

[wolfs]

@melix Did you already open an issue on gradle/gradle for this problem? I suppose we could do different things when we can't detect the toolchains from the registry and fall back to some known locations. You can also disable toolchain detection and provide the list of paths manually I suppose.

[melix]

There was an issue in gradle/gradle which was closed in favor of this one: https://github.com/gradle/gradle/issues/16656

Since yesterday I have setup a Windows 10 VM and I can confirm the same behavior happens in a VM, so it's not specific to GitHub actions.

[guai]

bump. In my case the error is different:

Caused by: org.gradle.internal.nativeintegration.NativeIntegrationUnavailableException: WindowsRegistry is not supported on this operating system.
        at org.gradle.internal.nativeintegration.services.NativeServices$BrokenService.invoke(NativeServices.java:445)
        at com.sun.proxy.$Proxy48.getSubkeys(Unknown Source)
        at org.gradle.jvm.toolchain.internal.WindowsInstallationSupplier.getVersions(WindowsInstallationSupplier.java:76)
        at org.gradle.jvm.toolchain.internal.WindowsInstallationSupplier.find(WindowsInstallationSupplier.java:67)
        at org.gradle.jvm.toolchain.internal.WindowsInstallationSupplier.findAdoptOpenJdk(WindowsInstallationSupplier.java:84)
        at org.gradle.jvm.toolchain.internal.WindowsInstallationSupplier.findInstallationsInRegistry(WindowsInstallationSupplier.java:52)
        at org.gradle.jvm.toolchain.internal.WindowsInstallationSupplier.findCandidates(WindowsInstallationSupplier.java:46)
        at org.gradle.jvm.toolchain.internal.AutoDetectingInstallationSupplier.get(AutoDetectingInstallationSupplier.java:41)
        at org.gradle.jvm.toolchain.internal.AutoDetectingInstallationSupplier.get(AutoDetectingInstallationSupplier.java:26)

It tries to read SOFTWARE\AdoptOpenJDK\JDK under HKEY_LOCAL_MACHINE. Last week everything was ok, dunno what happened.

gradle 7.4.1
Microsoft Windows 10 Enterprise 10.0.19044 Build 19044
JVM:          11.0.11 (Oracle Corporation 11.0.11+9-LTS-194)

PS: I have no Adopt installed