Python unittest框架调用DLL触发0x80010108致命异常求排查方案

先处理前置的stat: embedded null character in path错误 #

这个错误是Python的os.stat无法处理包含\0空字符的路径，虽然暂时没导致崩溃，但可能引发资源泄漏或对象状态异常，进而影响后续COM组件的清理：

• 临时Hookos.stat定位问题源：在测试框架初始化代码中加入以下片段，打印触发错误的路径和调用栈：

  import os
  import traceback
  
  original_stat = os.stat
  def debug_stat(path, *args, **kwargs):
      path_str = str(path)
      if '\x00' in path_str:
          print(f"[DEBUG] Invalid path with null char: {repr(path_str)}")
          traceback.print_stack()
      return original_stat(path, *args, **kwargs)
  
  os.stat = debug_stat
  

• 排查路径来源：检查是DLL返回了带空字符的路径，还是Python层拼接路径时误插入了\0（比如处理二进制数据时的转换错误）。

解析0x80010108异常 #

这个错误码实际是RPC_E_DISCONNECTED（COM对象连接已断开），和Windows更新无关，是comtypes在_shutdown阶段尝试访问已被销毁的COM对象导致的：

• 启用comtypes调试日志：在代码开头添加import comtypes; comtypes.debug = True，会输出COM对象的创建、引用计数变化、释放日志，通过日志定位哪个对象在释放后仍被引用。
• 检查COM对象生命周期：确认测试用例中，通过DLL间接创建的COM对象是否被正确释放，有没有出现引用计数错误（比如DLL内部创建对象但未交给Python层管理，导致提前被系统销毁）。

定位DLL导致的段错误 #

• 使用Windows调试工具直接抓崩溃现场：
  1. 启动测试前，用cdb（或WinDbg）附加到Python进程：

     cdb -p <你的Python进程PID>
     

  2. 输入g命令让程序继续运行，触发段错误后，输入k查看完整调用栈，确认是DLL的哪个函数引发崩溃。
• 验证参数合法性：检查传入DLL函数的参数（比如之前发现的带空字符的路径）是否符合DLL的要求，是否存在无效指针、类型不匹配的情况。
• 检查兼容性：确认DLL与Python的位数（32/64位）一致，且DLL依赖的系统库（如MSVC运行时）版本符合要求。

隔离测试验证 #

• 编写最小化测试用例：仅加载目标DLL并调用可疑函数，不引入unittest框架和其他依赖，验证是否能复现问题，排除框架本身的干扰。
• 逐步恢复依赖：在最小用例基础上逐步添加原框架的依赖，定位是否是某部分逻辑与DLL交互时引发的冲突。

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