问题标签 [dependency-walker]

恐怕 Dependency Walker 不支持这一点，但我需要确保我没有遗漏任何东西。

我有一个依赖于许多 DLL 的 Visual C++ 应用程序。其中之一是作为 C# 项目编写的 DLL（因此启用了 CLR 支持）。在.vcxproj配置文件中，我可以看到像这样的附加依赖项......

调用了 C# 项目XLibrary.dll——显然它不在该列表中。那是因为它已包含在以下标签中...

当我运行 Dependency Walker 时，我可以看到标签内的所有这些 DLL <AdditionalDependencies>，但我看不到XLibrary.dll

Dependency Walker 是否缺少 CLR 支持？

我有一个使用 3 个 DLL 的小型 C 程序。它使用第一个 DLL 中的 8 个函数。来自第二个 DLL 的 5 个函数。以及来自第 3 个 DLL 的 2 个函数。

问题 1) 当我使用 Dependency Walker 打开输出的可执行文件时，可执行文件仅尝试从每个 DLL 导入 2 个函数。这不可能。

问题 2) 更糟糕的是，它试图从每个 DLL导入相同的 2 个函数。但是只有一个 DLL 具有它甚至试图导入的这两个函数。所以可执行文件会抛出一个错误，说它找不到函数。但它当然不能，因为它正在查看显然没有该功能的 DLL。

问题）我该如何解决这个问题？我想用 Dependency Walker 打开可执行文件，并看到它尝试从第一个 DLL 导入 8 个函数。来自第二个 DLL 的 5 个函数。以及来自第 3 个 DLL 的 2 个函数。我希望看到它尝试从正确的 DLL 导入正确的函数。

希望有人可以根据上面的信息帮助我。但如果没有，希望我可以编辑这个问题，我将包括所有细节，包括程序的源代码（它是一个文件并且很短）。Dependency Walker 的屏幕截图。.h、.lib 和 .dll 文件的链接（它们是 libx264 的一部分）。以及 Visual Studio 中所有设置的屏幕截图，这些设置是让程序在没有任何错误的情况下构建。

附加信息...

抱歉，我是 C 编程新手，但我会尽量提供足够的信息。

以下是使用 libx264（或者可能是在幕后使用 libx264 的 ffmpeg API）的 C 程序，该程序手动绘制原始 RGB 图像（作为 uint8_t 数组），将它们提供给 libx264 编码器，从编码器接收单个 x264 帧，以及将 x264 帧写入文件（作为 uint8_t 数组）。然后可以将这些 x264 帧馈送到解码器。但是这个程序只是编码。

该行#pragma warning(disable : 4996)忽略了被视为错误的折旧警告。您可以看到我正在使用的一些函数在头文件中被标记为已弃用。稍后我会担心这个，现在我只需要一些可以运行的东西。

.h、.lib 和 .dll 文件可在此处找到：https ://ffmpeg.zeranoe.com/builds/

该站点上有一些下载选项：下载选项的屏幕截图

我正在使用 .h、.lib 和 .dll 文件的 64 位 beta 版本。您还必须选择是否要下载文件的“静态”、“共享”或“开发”版本。“共享”版本具有 .dll 文件。“Dev”版本具有 .h 和 .lib 文件。所以我需要这两个。

有人建议我不要在 Visual Studio 中发布设置的屏幕截图，但我会总结一下我在 Visual Studio 中为构建程序所做的工作。我必须确保项目设置为 64 位输出（默认为 32 位）。我不得不告诉 Visual Studio 编译和链接 C 而不是 C++ 代码（也许我通过将源代码文件扩展名重命名为 .c 而不是 .cpp 来做到这一点，我不记得了）。我将包含 .lib 文件和 .h 文件的文件夹放在我的项目文件夹内的一个逻辑位置，并将文件夹路径添加到 Visual Studio 将查找 .lib 文件和 .h 文件的位置。我还必须专门命名我正在使用的 .lib 文件。构建后，我将 .dll 文件与已编译的可执行文件放在同一文件夹中。可能还有别的东西，但我不记得了。

我还被建议不要制作 Dependency Walker 的屏幕截图，而是粘贴命令的输出：

dumpbin /imports LibLinkingTest.exe

LibLinkingTest.exe 是从上面的 C 源代码编译的可执行文件的名称，基于我给我的项目的名称。以下是上述命令的输出：

Microsoft (R) COFF/PE Dumper 版本 14.12.25835.0 版权所有 (C) Microsoft Corporation。版权所有。

文件 LibLinkingTest.exe 的转储

文件类型：可执行图像

部分包含以下导入：

概括

它将上述 C 源代码中使用的函数sws_getCachedContext与sws_scale3 个 DLL 相关联：avcodec-58.dll、avutil-56.dll 和 swscale-5.dll

但是这些函数sws_getCachedContext只sws_scale存在于 swscale-5.dll 中。

上面的 C 源代码中没有提到应该从这些 DLL 加载的 13 个其他函数。

上述 C 源代码中的函数avcodec_find_encoder, avcodec_alloc_context3, avcodec_encode_video2, avcodec_open2, avcodec_close, avcodec_register_all,av_packet_unref和av_init_packet应从 avcodec-58.dll 加载。

上述 C 源代码中的函数av_opt_set、av_image_alloc、av_free、av_freep和av_frame_free应从 avutil-56.dll 加载。

上面的函数sws_getCachedContext和sws_scaleC 源代码应该从 swscale-5.dll 加载（所以看起来它实际上是正确的）。

这些函数肯定存在于这些 DLL 中，因为我可以使用 Dependency Walker 在 DLL 中看到它们。我很确定这些函数都没有静态嵌入到最终的可执行文件中。所有这些函数都应该从 DLL 中加载。

并建议我发布构建日志。这是构建日志：

Microsoft (R) C/C++ 优化编译器版本 19.12.25835 for x64
版权所有 (C) Microsoft Corporation。版权所有。

cl /c /ZI /W3 /WX- /diagnostics:classic /sdl /Od /D _DEBUG /D _CONSOLE /D _UNICODE /D UNICODE /Gm /EHsc /RTC1 /MDd /GS /fp:precise /permissive- /Zc: wchar_t /Zc:forScope /Zc:inline /Fo"x64\Debug\" /Fd"x64\Debug\vc141.pdb" /Gd /TC /errorReport:prompt LibLinkingTest.c

LibLinkingTest.c
Microsoft (R) 增量链接器版本 14.12.25835.0
版权所有 (C) Microsoft Corporation。版权所有。

"/OUT:C:\Users\me\Desktop\Programming\Windows\VS2017\LibLinkingTest\x64\Debug\LibLinkingTest.exe" /INCREMENTAL avcodec.lib avdevice.lib avfilter.lib avformat.lib avutil.lib postproc.lib swresample .lib swscale.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /MANIFEST "/MANIFESTUAC:level=' asInvoker' uiAccess='false'" /manifest:embed /DEBUG:FASTLINK "/PDB:C:\Users\me\Desktop\Programming\Windows\VS2017\LibLinkingTest\x64\Debug\LibLinkingTest.pdb" /SUBSYSTEM:CONSOLE / TLBID:1 /DYNAMICBASE /NXCOMPAT "/IMPLIB:C:\Users\me\Desktop\Programming\Windows\VS2017\LibLinkingTest\x64\Debug\LibLinkingTest.lib" /MACHINE:X64 x64\Debug\LibLinkingTest.obj x64\Debug \stdafx.obj
LibLinkingTest.vcxproj -> C:\Users\me\Desktop\Programming\Windows\VS2017\LibLinkingTest\x64\Debug\LibLinkingTest.exe

相当简单的问题，但我似乎无法在他们的命令行帮助中找到这是否是一个选项。无论如何将依赖walker的内容直接输出到控制台？

是的，我知道您可以将其指定为输出到文件，然后我可以解析该文件，但这需要大量时间，我宁愿避免。

我不一定担心它在控制台中看起来有多“丑陋”。我可以通过编程快速从输出中搜索我想要的内容，只需要知道这是否可能。

如果您能提供任何建议，请提前致谢！

我使用 Dependency Walkerwintrust.dll在我的 Windows 10 上打开，大约需要 40 秒！当它打开时，我看到KERNEL32.DLL和之间重复调用的非常奇怪的画面API-MS-WIN-CORE-PROCESSTHREADS-L1-1-1.DLL：

我想这就是问题的根源。当我尝试打开自己的 dll（包括wintrust.dll在不同路径上）时，可能需要长达 10 分钟（！）才能打开。

为什么会这样？

• Win64 的 Dependency Walker，v2.2.6
• Windows 10 x64 版本 1709（操作系统内部版本 16299.248）
• wintrust.dll 文件版本 10.0.16299.248
• kernel32.dll 文件版本 10.0.16299.15
• api-ms-win-core-processthreads-l1-1-1.dll 文件版本 10.0.10586.9

检查 dll 时，依赖遍历器报告Error: A circular dependency was detected.

文件说

检测循环依赖错误。这是一个非常罕见的错误，但可能发生在转发函数中。

在这种情况下，转发函数意味着什么？

PS：替代依赖项似乎没有给出错误输出。

我有一个大约 10 个项目的解决方案，混合了 c# 和 C++，它们使用 VS 10 作为 DLL 构建并使用 VC++ redist 10 运行。它使用各种第三方库，如 protobuf、gtest、openssl 等全部使用 vs 10 构建工具集。因此，应用程序用于在运行时顺利加载这些库 dll。

现在我必须升级项目并在 VS 17 中构建解决方案，即工具集 15.0。我也构建了所有项目和第三方库。

但是我正在使用这个第三方 Microsoft SCOM SDK 库，我无法使用工具集 15.0 构建它

当我运行我的应用程序时，它无法加载基础 dll，即项目 dll 本身（它又链接到 Microsoft scom SDK dll）。

dependency walker 显示该项目的 dll 仍然依赖于一些 vc++ 10 库，尽管它是使用 vs2017 的最新工具集 15.0 构建的。

在进行迁移时，我们真的必须重建每个依赖的 dll，包括在运行时链接的第三方 dll 吗？

1. 我的理解正确吗？

2. 依赖遍历器是否显示唯一提到的 dll 的依赖库或递归地显示它所依赖的所有 dll 的依赖库？

3. 有没有其他的方法来处理这个？

我正在尝试运行某个程序（PCXS2），但是在使用 Dependency Walker 查看 .exe 后，我发现我需要 2 个特定的 .dll 文件（ext-ms-win-ntuser-uicontext-ext-l1-1 -0.dll 和 api-ms-win-core-shutdown-l1-1-1.dll），但该程序只接受 x86 dll 文件，并且唯一可用的版本是 x64 文件。如何将 dll 文件转换为 x86？

我在运行 Windows 8.1 的 64 位计算机上，并且为我的操作系统安装了大部分 vcredist 补丁。我曾尝试将文件放入 System32 并在 cmd 中运行 dll 注册代码，但无济于事。

我在运行 Dependency Walker 时得到的文本：

错误：由于隐式依赖模块中缺少导出函数，至少一个模块具有未解析的导入。

错误：发现具有不同 CPU 类型的模块。

警告：由于延迟加载依赖模块中缺少导出功能，至少有一个模块存在未解析的导入。

（对于上下文，CPU 值以红色突出显示。）

我有一个 DLL，但没有它的源代码。我想在这个 DLL 中调用一个方法。

现在在这张图片中。可以看到我要访问的是Test2.DLLwhich have fb1_CheckSensorMethod。但它位于 Test1.DLL 中

所以可以说我只有一个选择，那就是加载 1 个 DLL。仅适用于 JAVA 的 Test1.DLL

现在对于实现上述接口的类

所以这里的问题是。我不会到达 Test2.DLL 因为我实际上试图调用接口的地方是来自 Test1.DLL

我只能加载 Test1.DLL，我无法将 Test2.DLL 作为另一个实例加载。我怎样才能通过加载 Test1.DLL 作为父级来访问 Test2.DLL。

最近我遇到了一个问题，似乎我用 Dependency Walker 打开的每个 DLL 都会出现如下错误：

（Dependency Walker Module Error - "c:\windows\syswow64\MSVBVM50.DLL" 由于循环依赖而无法加载。）

我以 MSVBVM50 为例，但这也发生在其他 DLL 的负载上。单击确定并让它打开后，会发生以下情况：

加载需要一点时间，我认为最终它会达到某个最大深度并停止进一步加载（因为它不会挂起/崩溃）。

API-MS-WIN-CORE-PROCESSTHREADS-L1-1-0.DLL这种依赖于KERNEL32.DLL等的循环根源KERNEL32是Windows的核心部分......这怎么可能/这是什么意思？我可以修复它吗？

在 Windows 10 上运行。

我.pyd在 Visual Studio 2019（社区）中构建了一个，它为仅存在于 LibRaw 中的某些功能提供了一个包装器。该解决方案编译成功，没有任何警告或错误。该项目使用 LibRaw、OpenCV 和 pybind11 以及Python.h相应的.lib-file。

当我尝试导入.pydPython 解释器内部时，我得到：

所需的路径.dlls（在本例中为 Python 和 OpenCV；LibRaw 完全静态链接）在系统路径中设置。

我运行了 Dependency-Walker，但找不到任何可疑的东西。这是相应的 Dependency Walker 图像。我还尝试了另一个工具（Dependencies.exe，它本质上是对 Dependency Walker 的重写，但考虑到了API-MS-WIN-CORE-....dlls）并得到了一个错误，如下所示：

当我将鼠标悬停在失踪者上.dll时，我可以看到一个api-ms-win... module could not be found on disk. 我已经搜索并找到了该模块并将其目录路径添加到系统路径中。现在该模块不再以红色突出显示，但C:\WINDOWS\SysWOW64\WS2_32.dll（屏幕截图顶部的红色突出显示）仍然显示缺少导入。这可能是一个问题吗？

我是如何制作的.pyd：

• 创建空的 Visual Studio 项目（Win32；Python 也是 32 位安装）
• 将项目设置更改为.dll-configuration 和.pyd-fileextension
• 为 OpenCV、LibRaw 和 Pybind11 的头文件添加了包含路径
• 为 OpenCV、LibRaw 和 Python3.8 的链接器添加了路径和输入文件
• 构建解决方案（无错误，无警告）
• 试图导入.pydpython解释器中的结果

我已经看到了这个问题，其中 OP 遇到了.dlls库加载不同 Python 的问题，但在我的情况下，Dependency Walker 引用的库与我的路径变量中的库相同。