客户正在使用我们的 dll，该 dll 正在创建一个使用开源库的子进程，最终由于调用 LoadLibraryExW() 而失败，最后返回的错误是 ERROR_MOD_NOT_FOUND。 在 WinXP 32 位上会出现这种情况，但在其他计算机上不会出现这种情况。 但我们知道安装了正确的依赖项集，甚至在同一目录中。
因此我们很自然地想到，使用 Dependency Walker 来查找该特定机器上缺少的依赖项。 不幸的是，它没有显示任何缺失，只是一些延迟加载警告，这些警告不是库的直接依赖项。 根据我的经验，使用depends.exe 总是能揭示缺少的依赖项是什么。
所以此时我已经绞尽脑汁试图理解如果所有库的依赖项都存在的话为什么我会收到 ERROR_MOD_NOT_FOUND ？ 使这台机器独一无二的另一件事是它非常安全，因为它由政府使用，但如果我们遇到访问/权限问题，我会期望出现不同类型的错误代码。
我构建了一个小型 Win32 可执行文件，它除了在所述库上调用 LoadLibraryExW() 之外什么也不做，当它从库所在的同一目录运行时，它会在客户有问题的机器上毫无问题地加载库。
有一件事是，我们的产品是一个 ActiveX 插件，它启动一个子进程，子进程调用第 3 方库，第 3 方库存在有问题的 LoadLibraryExW() 调用。 那么也许它失败的原因是它正在运行的上下文（例如来自浏览器）？
最好的方法是使用加载器快照。 基本上，您使用 gflags.exe（包含在 Windbg 中）来启用加载程序快照；然后，使用附加的调试器运行该进程。 加载器快照将使加载器能够打印出进程的 dbg 消息，并且它将打印失败。
gflags.exe -i yourcode.exe +sls
windbg yourcode.exe
在应用程序上使用 Dependency Walker 的 Profiling 选项。可能该库正在尝试动态解析某些 API（使用 LoadLibrary/GetProcAddress），而这不会显示在静态依赖项中。
您的依赖项可能存在于系统上，但它们可能位于不属于 LoadLibraryExW() 期间搜索顺序的文件夹中。 SetDllDirectory() 或 AddDllDirectory() 调用将确保在 LoadLibraryExW() 调用期间搜索包含依赖项的文件夹
我的头发也被这个撕掉了。 （必须再买一些落建）。对我来说，问题是我打开了一个在 RELEASE 模式下编译的应用程序，它试图加载在 DEBUG 模式下编译的资源 DLL。