> Everything succeeds, then we get an extra successful request for FlsFree then it immediately returns with a fail.

That makes it sound like the CRT is uninitialising itself, so this may be a conflict between statically linked vcruntime140.dll and dynamically linked. More likely to occur with msvcp140.dll in the mix, since CPython does not include it.

I'm not seeing full paths for the dependent DLLs, so I have no way to know whether it's mixing and matching versions. CPython installs include vcruntime140.dll, which should be the one loaded by python.exe. However, there are some extension modules that statically link what is required from it, and that should lead to multiple FLS calls when the embedded CRT initialises/uninitialises its state. That will happen during DLL load, but normally fails with a more obvious error than what you're getting.

However, if you've got a different version msvcp140.dll, it might be managing to load a mismatched vcruntime140.dll. Or something that's happening during initialisation (which should include C++ stuff) is failing in a way that doesn't bubble out properly.

Looking through "C:\Program Files (x86)\Windows Kits\10\Source\10.0.19041.0\ucrt\internal\initialization.cpp" (on my machine at least, yours may be different), there's *a lot* that could fail.

If you're able to coerce a _jpype build that links to vcruntime140d.dll/msvcp140d.dll (the debug versions, typically specified with /MDd instead of /MD to the compiler - might require patching setuptools though), and use a CPython debug build, you may get a more informative failure. If not, I can try and find someone from the C++ libraries team at Microsoft to help out, but that's not going to happen until early January at this point of the year.