Exception 0xC0000005 from JNI_CreateJavaVM (jvm.dll)

I am initializing the Java VM using the following C++ code. JNI_CreateJavaVM throws a 0xC0000005 exception but succeeds none the less if I ignore it.

'Jni.exe' (Win32): Loaded 'C:\Tools\Java\Jdk8.77x86\jre\bin\zip.dll'. Cannot find or open the PDB file.

Exception thrown at 0x02900282 in Jni.exe: 0xC0000005: Access violation reading location 0x00000000.

'Jni.exe' (Win32): Loaded 'C:\Windows\SysWOW64\shell32.dll'. Cannot find or open the PDB file.

Am I forgetting to set or do something or is this 'normal' behaviour?

#include <array>
#include "jni.h"

int main( int argc, char const* args[])
{
    JavaVM* jvm;
    JNIEnv* env;

    std::array<JavaVMOption,1> options;
    options[0].optionString = "-Djava.class.path=C:/Users/Thomas/Documents/Visual Studio 2015/Projects/Jni/x64/Debug";
    options[0].extraInfo = nullptr;

    JavaVMInitArgs vm_args;
    vm_args.version = JNI_VERSION_1_8;
    vm_args.options = options.data();
    vm_args.nOptions = options.size();
    vm_args.ignoreUnrecognized = false;

    auto rc = JNI_CreateJavaVM( &jvm, reinterpret_cast<void**>(&env), &vm_args );
    if( rc == JNI_OK )
    {
        jvm->DestroyJavaVM();        
    }
}

This happens for both Release and Debug and for both x86 and x64 builds.

JVM actively uses OS signals (or exceptions in Windows terminology) for its own purposes:

• for implicit null pointer checks and stack overflow checks;
• for safepoint polling;
• for remote memory barriers;
• etc.

SEGV (or exception 0xC0000005) is also generated intentionally on JVM startup to verify certain CPU/OS features. Some OSes or hypervisors had a bug that AVX registers are not restored after signal processing. Therefore, JVM needs to check whether this is the case (the source). So it generates an exception by writing to zero address and then handles it.

This is what happens in your case. And yes, it is normal.