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
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).