What version of Go are you using (go version)?

$ go version
go version go1.20 windows/amd64

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

go env Output
$ go env
set GO111MODULE=
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\green\AppData\Local\go-build
set GOENV=C:\Users\green\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\Users\green\go\pkg\mod
set GONOPROXY=github.com/MetaFFI/*,github.com/GreenFuze/*
set GONOSUMDB=github.com/MetaFFI/*,github.com/GreenFuze/*
set GOOS=windows
set GOPATH=C:\Users\green\go
set GOPRIVATE=github.com/MetaFFI/*,github.com/GreenFuze/*
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\Program Files\Go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\Program Files\Go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.20
set GCCGO=gccgo
set GOAMD64=v1
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=NUL
set GOWORK=
set CGO_CFLAGS=-O2 -g
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-O2 -g
set CGO_FFLAGS=-O2 -g
set CGO_LDFLAGS=-O2 -g
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=c:\temp\go-build2999029303=/tmp/go-build -gno-record-gcc-switches

What did you do?

The following code crashes when "var testingWER bool" at "runtime/signal_windows.go:168" is false.

package main

/*
#include <Windows.h>
#include <stdio.h>

typedef struct JavaVMInitArgs {
    int version;

    int nOptions;
    void *options;
    unsigned char ignoreUnrecognized;
} JavaVMInitArgs;

void create_jvm()
{
    HMODULE h = LoadLibrary("C:\\Program Files\\Microsoft\\jdk-11.0.18.10-hotspot\\bin\\server\\jvm.dll");
    void* create = GetProcAddress(h, "JNI_CreateJavaVM");

    JavaVMInitArgs vm_args;
    vm_args.version = 0x000a0000; //JNI_VERSION_10
    vm_args.nOptions = 0;
    vm_args.options = 0;
    vm_args.ignoreUnrecognized = 0;

    void* pjvm = 0;
    void* penv = 0;

    printf("Before calling JNI_CreateJavaVM\r\n");
    ((void(*)(void**, void**, JavaVMInitArgs*))create)(&pjvm, &penv, &vm_args);
    printf("After calling JNI_CreateJavaVM\r\n");
}
*/
import "C"

func main(){
    C.create_jvm();
}

Changing "var testingWER bool" to true, makes the application work fine.

What did you expect to see?

That it doesn't crash

What did you see instead?

JNI_CreateJavaVM crashes with ACCESS_VIOLATION.

Resolution Suggestions

The problem is that an ACCESS_VIOLATION generated by JNI (and caught by it) is not getting caught, due to the fact that Go doesn't continue the exception search (i.e. _EXCEPTION_CONTINUE_SEARCH).

Patching Go to "testingWER=true" forces Go to continue the search, allowing JNI to handle the error.

As a short term solution, I suggest making "testingWER" public, so developers can workaround unexpected issues without patching Go.

As a long term solution, signal_windows.go return _EXCEPTION_CONTINUE_SEARCH in case the Go module is a library or an archive. I suggest doing one of the following

  1. Return _EXCEPTION_CONTINUE_SEARCH if CGo is being used, as stepping out of "Go runtime" might require custom handling of an exception.
  2. Provide a function to the user to replace "lastcontinuehandler" in signal_windows.go with their own. I think this is the best option, as we reach this point after Go realizes it cannot handle the exception, so let the user take some action. You can also pass as a parameter to the user's custom "lastcontinuehandler" the code which throws the exception (the winthrow() function).

Comment From: bcmills

(CC @golang/windows)

Comment From: bcmills

Compare #57441, #52763, #19465.

Comment From: qmuntal

Also related to #56082 #47576 and #12516

Comment From: GreenFuze

In version go1.21.1, testingWER has been removed, but JVM still crashes. Currently I cannot find a workaround to load JVM using JNI_CreateJavaVM in windows.

Can anyone offer a workaround?

Comment From: qmuntal

I have some CLs (CL 525475 and CL 457875) in flight that will teach the Go runtime to not crash when an exception is catch and handled by a SEH exception handler. This should fix your issue.

Can anyone offer a workaround?

If you were patching Go before, I suggest you to continue doing that, i.e. readding testingWER.

Comment From: mpetavy

Hi, wanted to ask if there will be a fix in a next GO release in the near future with the fixes as mentioned above? Thanks for an update.

Comment From: qmuntal

Not yet, I couldn't land CL 457875 in time because I got sidetracked by an important missing piece in the SEH machinery (see CL 534555).

My plan is to fix this issue in go 1.23.

Comment From: gopherbot

Change https://go.dev/cl/457875 mentions this issue: runtime,cmd/link: use SEH instead of vectored exception handlers