[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Okay, well at least now googling Python + "A dynamic link library (DLL) initialization routine failed." give something which could point a user may be able to identify the issue. It wasn't obvious to me that imports did not hold the GIL, but it is clear in

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: I doubt there's anything more we can do about Windows swallowing an access violation and turning it into a generic error. There's a very low chance you'd have found any notes about it in the docs, so this bug will probably stand as the best available reference

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I found it. The change that hit JPype is https://bugs.python.org/issue33895 Thanks, Eryk Sun for figuring this out. I would never have gotten myself. -- ___ Python tracker

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Drat I missed that one when I was scanning for statics because I was focusing C++ resource rather than looking for Python resources. I also wouldn't have expected this to happen on only one platform, but that was my bad. Is it possible to improve the error

[issue42529] CPython DLL initialization routine failed from PYC cache file

Eryk Sun added the comment: I built JPype normally in release mode and was able to analyze the problem using the platform debugger (cdb or WinDbg). I think the issue is pretty straight forward. The static initializer for classMagic in "native\python\pyjp_class.cpp" is calling PyDict_New().

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Gave another series of shots at the problem. So the reason that attaching the debugger fixes the issue is that it calls LoadLibraryExW for a bunch libraries when it attaches. I was also able to unconditionally trigger the bug even when loading without the

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I will look through the list of samples in Detours to see if there is something that can give us better stacktrace information. If we really need a stack trace I can make Detours bust by creating an intentional segfault and see if we can attach the debugger

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: > I recommend first doing a capture of these functions first I don't think that'll be necessary - the logging output ought to be enough. Capturing or redirecting those functions would be great if the debugger was working, but since that spoils it, it's not. >

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: I recommend first doing a capture of these functions first, incase Windows is routing some through them: LoadLibrary(Ex)(W|A) W is the Unicode variant while A is the Ascii variant. -- ___ Python tracker

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I looked more at the logs to see if I can find out what to instrument next. The log files unfortunately don't diff well because every line contains a timestamp so I can't a proper alignment as well as all the real addresses. So I wrote a short program to

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Eryk, Unfortunately, this particular bug is resistant to attaching the debugger. Whenever the debugger is attached the bug disappears. Fortunately the suggestion to use Detours by WildCard65 appears to offer a way to diagnose the issue. --

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: Msvcp140.dll from what I can find is part of the VS 2015 Redstributable package. -- ___ Python tracker ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Looking at the winapi_thunks.cpp source file from the CRT, it may be that LCIDToLocaleName is failing to be loaded for some reason. That's the one that comes after LCMapStringEx, so if it's failing, that could abort the whole process. Alternatively,

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: > 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

[issue42529] CPython DLL initialization routine failed from PYC cache file

Eryk Sun added the comment: > ImportError: DLL load failed while importing _jpype: > A dynamic link library (DLL) initialization routine failed. With loader snaps enabled for python[_d].exe (i.e. loader debug messages), you can attach a debugger to discover which DLL's init routine is

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: The last libraries loaded prior to the failure were... ``` 20201218192451066 20440 50.60: trclnk64: api-ms-win-eventing-provider-l1-1-0.dll [7ffc4c974108 7ffc4c8b7808] 20201218192451066 20440 50.60: trclnk64: EventUnregister0 7ffc4eab37a0

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: I was just expecting only detours for LoadLibraryExW (and variants) to find out which dll failed. -- ___ Python tracker ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I used Detours with trclnk64 to get the following log: ``` 20201218193836960 4332 50.60: trclnk64: 001 GetProcAddress(,) -> 7ffc4ccebef0 20201218193836960 4332 50.60: trclnk64: 001 GetProcAddress(7ffc4ccd,LCMapStringEx) 20201218193836960 4332 50.60:

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: https://www.microsoft.com/en-us/research/project/detours/ -- ___ Python tracker ___ ___

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Can you be so kind as pointing me to a LoadLibraryExW detour example for Python? I have shimmed a DLL before to capture transaction logs in the past, but not with a Python or a system library. -- ___ Python

[issue42529] CPython DLL initialization routine failed from PYC cache file

William Pickard added the comment: You may need to inject a LoadLibraryExW detour into your python runtime before _jpype is loaded and output all the library names its requesting. You may need to detour all Load Library functions for maximum coverage. -- nosy: +WildCard65

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Just for reference here are all the dependencies that _jpype has ``` MSVCP140.dll python39.dll

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I attempted another deep dive on this one. 1) Removed manual library add platform_specific['libraries'] = ['Advapi32'] No change. 2) Compared symbol wise imports Two imports changed PyIndex_Check PyObject_CheckBuffer plus one additional "fflush" dependency

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Well that gives me a place to search from. Unfortunately statics are not likely the source of the issue. I scrubbed all C++ structures from the project into a big structure which has only a single global pointer which I initialize in the init method. It

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: You'll find it leads up to a LoadLibraryExW call in Python/dynload_win.c that is failing with ERROR_DLL_INIT_FAILED (1114) in GetLastError(). From that point on, it's looking solely at _jpype.pyd and its dependencies, and it could be any of them failing to

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Without the pyc everything goes fine... ``` ... _bootlocale' # <_frozen_importlib_external.SourceFileLoader object at 0x0222E9FD5A30> import 'site' # <_frozen_importlib_external.SourceFileLoader object at 0x0222E9F88F40> Python 3.9.0

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Thanks, I will see if I can get additional diagnostics today. Otherwise I will have to start recompiling Python with diagnostic hooks. I have never had to rebuild python on windows so it may take a while to figure out how to make progress. The monkey patch

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Monkeypatching native types looks suspect as anything, but probably not the cause here. Good luck :) So I checked some of our code around dynamic loads and it's got to be caused by the loader in our LoadLibrary call, not when we call your module init function.

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I am fairly sure this is a Python "bug" in the sense that there was some change in undocumented change in requirements and the distutils pattern for building a module no longer reflects that requirement. That said very likely JPype is the only module to be

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Sorry, I haven't had a chance to set up a test machine with all the requirements. It's almost certainly something in jpype, to be clear. Most likely it loads a DLL that hasn't been loaded yet, but does it under conditions where it won't load. Nothing we build

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Any progress on this item? I am seeing additional reports of this error in the conda stream tracker and elsewhere. As it only occurs when the debugger is not hooked up I don't have much traction to make progress myself. --

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: Oddly that was the only exception that I got. When I hit continue it proceeded without issue and the dll was loaded correctly. However, when I try without the debugger attached the error reappears. So this is one of those Schrodinger errors. I know the

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: Replicating also requires installing Java (I got as far as the build failing), which is going to have to wait until I have time to spin up a throwaway machine :) That exception is a normal part of the import process and should be being handled. It's not the

[issue42529] CPython DLL initialization routine failed from PYC cache file

Karl Nelson added the comment: I managed to get the debugger attached (unfortunately I am not a windows programmer so I don't use these tools). It appears when loading from a pyc, it is attempting to open the directory as a Zip file which is throwing an exception resulting in a failure to

[issue42529] CPython DLL initialization routine failed from PYC cache file

Steve Dower added the comment: There really shouldn't be any difference between those two paths, apart from skipping the compile step in the second case. It sounds like you're pretty well set up for testing, so would you be able to try the test while running under either the Visual Studio

[issue42529] CPython DLL initialization routine failed from PYC cache file

New submission from Karl Nelson : While trying to use JPype on Windows Python 3.9.0, we are running into an bizarre issue with loading the internal module which is written in C. When running a python script the first time the internal module loads correctly. However, the second time that