Windows actions

[neykov]

I've asked Claude to reproduce the failure in Issue 7. It needed a lot of handholding, but eventually was able to come up with a clean repro case.

ServiceConfigurationError: WindowsAttachProvider could not be instantiated

Error

java.util.ServiceConfigurationError: com.sun.tools.attach.spi.AttachProvider:
  Provider sun.tools.attach.WindowsAttachProvider could not be instantiated

Root Cause

On Windows with Oracle JDK 8, two separate Java installs coexist:

• A JDK at C:\Program Files\Java\jdk1.8.0_XXX\ — has tools.jar and jre\bin\attach.dll
• A standalone public JRE at C:\Program Files\Java\jre1.8.0_XXX\ — has no attach.dll

Oracle's installer puts the public JRE's bin\ on the system PATH. Users separately set
JAVA_HOME to the JDK for development tools. This creates the failing combination:

Component	Source	Has attach.dll?
java.exe on PATH	Standalone public JRE	—
jvm.dll loaded	Standalone JRE bin\server\	—
sun.boot.library.path	Derived from jvm.dll location → standalone JRE bin\	No
tools.jar (via JAVA_HOME)	JDK lib\tools.jar	✓

Key facts

• The standalone JRE does not ship attach.dll — it is only present in the JDK's embedded JRE
  (jdk\jre\bin\attach.dll).
• sun.boot.library.path is derived purely from the location of the running jvm.dll, not
  from JAVA_HOME. It always resolves to the bin\ directory two levels above jvm.dll:

  jvm.dll at:  standalone_jre\bin\server\jvm.dll
               ↓ strip \jvm.dll
               standalone_jre\bin\server
               ↓ strip \server
               standalone_jre\bin
               ↓ strip \bin, append \bin
  sun.boot.library.path = standalone_jre\bin   ← no attach.dll here
  

• System.loadLibrary("attach") searches sun.boot.library.path first, then java.library.path
  (derived from PATH). If neither contains attach.dll, loading fails.

Failure chain

1. java.exe is the standalone JRE's — com.sun.tools.attach.VirtualMachine is not on the
   classpath, so isAttachApiAvailable() returns false.
2. AgentAttach loads tools.jar from JAVA_HOME via URLClassLoader(cp, null).
3. VirtualMachine.list() triggers the SPI, which attempts to instantiate
   WindowsAttachProvider.
4. WindowsAttachProvider's static initializer calls System.loadLibrary("attach").
5. System.loadLibrary searches sun.boot.library.path = standalone JRE bin\ →
   attach.dll is absent.
6. UnsatisfiedLinkError is thrown inside the static initializer.
7. The SPI loader catches the Throwable and wraps it:

   ServiceConfigurationError: Provider sun.tools.attach.WindowsAttachProvider
     could not be instantiated
   

Variant failure

If any attach.dll is reachable via PATH (e.g. from a different JDK installation), but it is
from an older version than the tools.jar being used, the static initializer succeeds but a
later native method call fails:

java.lang.UnsatisfiedLinkError: sun.tools.attach.WindowsAttachProvider.tempPath()

tempPath() was added in a later JDK 8 update as a security hardening measure. An older
attach.dll on PATH will load successfully but will not contain this method.

---

Steps to Reproduce

name: Reproduce ServiceConfigurationError - standalone JRE on PATH with JDK JAVA_HOME

on:
  workflow_dispatch:

jobs:
  reproduce:
    runs-on: windows-latest

    steps:
      - uses: actions/checkout@v4

      - name: Set up Temurin JDK 8 (JAVA_HOME will point here)
        uses: actions/setup-java@v4
        with:
          java-version: '8'
          distribution: 'temurin'

      - name: Build jar
        run: mvn package -DskipTests -q

      - name: Download Temurin JRE-only archive (simulates Oracle standalone public JRE)
        shell: pwsh
        run: |
          $url = "https://github.com/adoptium/temurin8-binaries/releases/download/jdk8u442-b06/OpenJDK8U-jre_x64_windows_hotspot_8u442b06.zip"
          Invoke-WebRequest -Uri $url -OutFile jre8.zip
          Expand-Archive jre8.zip -DestinationPath jre8
          $jreHome = (Get-ChildItem jre8 -Directory)[0].FullName
          echo "STANDALONE_JRE=$jreHome" >> $env:GITHUB_ENV

      - name: Confirm preconditions
        shell: pwsh
        run: |
          Write-Host "Standalone JRE (simulates java.exe on PATH):"
          Write-Host "  path       : $env:STANDALONE_JRE"
          Write-Host "  attach.dll : $(Test-Path "$env:STANDALONE_JRE\bin\attach.dll")"
          Write-Host ""
          Write-Host "JDK (JAVA_HOME):"
          Write-Host "  path       : $env:JAVA_HOME"
          Write-Host "  tools.jar  : $(Test-Path "$env:JAVA_HOME\lib\tools.jar")"
          Write-Host "  attach.dll : $(Test-Path "$env:JAVA_HOME\jre\bin\attach.dll")"

      - name: Reproduce error
        shell: pwsh
        # Simulates: Oracle standalone JRE on PATH, JAVA_HOME pointing to JDK.
        # java.exe is from the standalone JRE  →  sun.boot.library.path = standalone JRE bin\
        # Standalone JRE has no attach.dll     →  System.loadLibrary("attach") fails
        # UnsatisfiedLinkError in static init  →  SPI wraps as ServiceConfigurationError
        run: |
          # Strip JDK directories from PATH so java.library.path also has no attach.dll fallback
          $env:PATH = ($env:PATH -split ';' |
            Where-Object { $_ -notmatch 'jdk|jre|java|hostedtoolcache' }) -join ';'

          $java = "$env:STANDALONE_JRE\bin\java.exe"
          $jar  = (Get-ChildItem target\extract-tls-secrets-*.jar)[0].FullName

          Write-Host "java.exe : $java  (standalone JRE — no attach.dll)"
          Write-Host "JAVA_HOME: $env:JAVA_HOME  (JDK — has tools.jar)"
          Write-Host ""
          & $java -jar $jar list
        continue-on-error: true