Anaconda环境ctypes.CDLL可加载DLL但Windows官方原生Python无法加载问题问询

• 核心触发点是Python 3.8版本的官方安全更新：为了解决Windows平台长期存在的DLL劫持漏洞，Python官方修改了ctypes的默认加载逻辑，收紧了DLL搜索路径范围。
• Anaconda作为面向数据科学的发行版，其内置的大量第三方二进制包（尤其是编译型扩展、MinGW编译的库）依赖旧版本的DLL搜索逻辑，为了保证生态兼容性，Anaconda维护团队对自带的ctypes模块做了定制化补丁，没有合并官方3.8+的安全修改，因此和原生Python的ctypes行为不一致。

具体差异点 #

Windows平台下两者的核心差异是ctypes.CDLL调用Win32加载API时传入的标志位不同：

• 原生Python 3.8+的ctypes：调用LoadLibraryExW时默认传入LOAD_LIBRARY_SEARCH_APPLICATION_DIR | LOAD_LIBRARY_SEARCH_SYSTEM32 | LOAD_LIBRARY_SEARCH_USER_DIRS组合标志，该标志明确跳过当前工作目录、PATH环境变量对应的路径，仅搜索以下受信任位置：
  • python.exe所在的安装目录
  • 系统System32目录
  • 调用os.add_dll_directory()显式添加的目录
• Anaconda版ctypes：沿用3.8版本之前的逻辑，调用加载API时传入0标志，遵循Windows默认DLL搜索顺序，会依次搜索当前工作目录、PATH环境变量路径、系统目录等位置。

为什么原生Python的ctypes无法从工作目录和PATH中查找DLL依赖 #

就是上述安全更新的直接结果：官方为了避免恶意程序在工作目录放置同名恶意DLL被正常程序误加载，主动禁用了这两个路径的默认搜索权限，用户如果需要加载这两个路径下的DLL，需要手动调用os.add_dll_directory(目标路径)显式添加到信任列表。

为什么先调用Anaconda的ctypes可修复原生ctypes的加载问题 #

Windows系统对同一进程内的DLL加载有全局缓存机制：当Anaconda版的ctypes成功加载目标DLL及关联的MinGW依赖DLL后，这些DLL会被映射到当前Python进程的地址空间中，系统会记录已加载的DLL名称和对应句柄。后续原生ctypes调用CDLL加载同名DLL时，系统会直接返回已缓存的句柄，不需要再走路径搜索流程，因此表现为加载成功。

内容的提问来源于stack exchange，提问作者Schlammkrabbe