This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author eryksun
Recipients The Compiler, eryksun, never-eat-yellow-snow, paul.moore, pombredanne, steve.dower, tim.golden, zach.ware
Date 2020-09-22.15:06:03
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1600787163.41.0.753215217084.issue25655@roundup.psfhosted.org>
In-reply-to
Content
> " OSError: [WinError 126] The specified module could not be found" is 
> raised when calling ctypes.CDLL(dll_path) even when this "dll_path" 
> exists... because the error comes from another DLL.

That's the old error. bpo-36085 changed it to FileNotFoundError, with the message "Could not find module '%.500S'. Try using the full path with constructor syntax." bpo-39393 modified the message to "Could not find module '%.500S' (or one of its dependencies). Try using the full path with constructor syntax."

IMO, the most direct way to resolve the problem is by enabling "loader snaps" for python.exe via gflags and attaching a native debugger to the process. The loader outputs debug strings that show the computed DLL search path (from LdrpComputeLazyDllPath), each attempt to resolve the dependent DLL to a directory in the search path (via LdrpResolveDllName), and the final result from loader's work queue (from LdrpProcessWork), which includes the dependent DLL that caused loading to fail and the parent module (DLL or EXE) that depends on it.
History
Date User Action Args
2020-09-22 15:06:03eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, The Compiler, pombredanne, never-eat-yellow-snow
2020-09-22 15:06:03eryksunsetmessageid: <1600787163.41.0.753215217084.issue25655@roundup.psfhosted.org>
2020-09-22 15:06:03eryksunlinkissue25655 messages
2020-09-22 15:06:03eryksuncreate