Win32 LoadLibrary返回错误6（ERROR_INVALID_HANDLE）的排查咨询

碰到这种偶发的加载失败确实头疼，我给你梳理几个实际调试的方向，都是平时排查这类问题常用的手段：

• 先确认fileName的「真实有效性」，别光靠肉眼判断
  你说fileName有效，但偶发问题往往出在「你以为有效，但加载瞬间文件状态变了」。在调用LoadLibrary前，加一段日志逻辑：

  1. 用GetFullPathName把相对路径转成绝对路径，输出完整路径（避免相对路径解析出错）；
  2. 调用GetFileAttributesW(fileName)，把返回值也记录下来——如果返回INVALID_FILE_ATTRIBUTES，说明加载瞬间文件确实不存在/不可访问；
  3. 把路径转成十六进制输出，排查有没有肉眼看不见的特殊字符（比如末尾空格、Unicode控制字符），这些很容易导致路径解析错误。

• 检查GetLastError的调用时机是否被污染
  看你的代码，printf是在GetLastError之后调用的，但printf本身可能会触发Win32 API调用，覆盖掉原本的错误码！正确的做法是先把错误码存到变量里再打印：

  if (!_handle) {
      DWORD err = GetLastError(); // 先存错误码，避免被后续API覆盖
      printf("LoadLibrary failed, error: %d\n", err);
      return false;
  }
  

  说不定原本的错误码不是6，是被printf改了，这一点很容易被忽略。

• 用工具跟踪加载全流程，抓细节
  偶发问题靠日志有时候不够，得用专业工具：

  • Process Monitor（ProcMon）：设置过滤条件（进程名是你的程序，操作选「Load Image」），然后运行程序直到出错，看加载插件时的详细日志——能看到文件是否被锁定、权限是否足够、依赖的DLL有没有加载失败等细节；
  • Dependency Walker（Depends.exe）：用它的「Profile」功能动态跟踪程序加载插件的过程，能看到每个依赖DLL的加载状态，甚至能定位到是哪个依赖项导致的加载失败。

• 排查竞态条件和外部进程干扰
  这类偶发问题很多时候是外部因素：

  • 如果是多线程加载插件，虽然LoadLibrary本身线程安全，但要确保插件的DllMain里没有线程不安全的操作（比如全局变量未加锁）；
  • 检查有没有其他进程在操作插件文件：比如杀毒软件实时扫描、备份程序、甚至你的其他模块在读写这个插件文件，导致加载瞬间文件被锁定。可以在出错时，用CreateFile尝试打开文件，看返回的错误码，对比LoadLibrary的错误码，判断是不是文件锁定问题。

• 系统层面和插件本身的排查

  • 检查系统的应用程序事件日志，里面可能会有更详细的加载失败记录；
  • 单独加载出错的插件：把插件拿出来写个简单的测试程序，循环调用LoadLibrary/FreeLibrary，看能不能复现问题——如果能，说明插件本身有问题（比如DLL损坏、DllMain逻辑有bug）；
  • 尝试修复系统文件：用sfc /scannow或者DISM /Online /Cleanup-Image /RestoreHealth命令修复系统，有时候系统的DLL缓存损坏会导致偶发加载失败。

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