什么时候用它
程序一启动就提示缺少 DLL，或者插件加载失败时，可以先用 Dependencies 看看这个 EXE / DLL 的依赖关系。它主要分析 Windows 原生 PE 文件，不是“一键修复 DLL”的工具，也不能替代程序自己的错误日志。
下面按下载、打开文件、定位问题的顺序记一下。示例路径都是占位路径，使用时换成自己的文件。
下载后，打开哪个程序？
从 官方 Releases 下载适合本机运行的压缩包，解压到一个独立目录，不要只把其中一个 EXE 拿出来。工具本身也需要 Visual C++ 运行库；无法启动时，先核对官方说明和报错。
DependenciesGui.exe：图形界面。日常查看依赖，打开这个。Dependencies.exe：命令行工具。双击后窗口一闪而过，不等于工具坏了，应该在终端里运行。
Visual C++ 运行库从 微软官方页面 获取。运行库架构要对应需要它的程序，而不是只看 Windows 是不是 64 位：32 位程序通常需要 x86 运行库。
图形界面：先查直接依赖
- 启动
DependenciesGui.exe，通过打开文件操作选择出问题的 EXE 或 DLL。先保留文件原本的发布目录结构，不要单独拷走再分析。 - 在依赖树中查看直接依赖，选中有疑问的模块，核对解析到的完整路径和架构信息。默认不会无限递归分析整棵树，需要时再展开下一级。
- 如果文件存在，继续看导入（Imports）与导出（Exports）：调用方需要哪个函数，被依赖的 DLL 是否提供它。只有文件名一样，不代表版本兼容。
- 记录模块名、路径、架构和原始报错，一次调整一个问题，再重新打开文件分析，并实际启动程序验证。
例如：app.exe → engine.dll → vendor.dll。程序提示 engine.dll 加载失败，问题也可能出在它依赖的 vendor.dll，不一定是 engine.dll 文件本身丢了。
几个容易看错的地方
- 缺少普通 DLL：先核对软件安装是否完整、发布包是否漏了文件。属于第三方 SDK 的，使用该 SDK 的正式安装包或自己构建时配套的依赖，不从陌生 DLL 下载站补文件。
- 架构不一致：核对 EXE、插件和它们的原生 DLL 是否配套。比如 x64 程序不能在同一个进程里直接加载 x86 DLL。不要凭电脑是 64 位就认定所有文件也是 x64。
- 同名 DLL：看完整路径，而不只看名称。静态分析解析到的路径不保证就是程序运行时加载的路径；程序可以改变 DLL 搜索顺序。必要时结合日志和运行时加载记录继续核实。
api-ms-win-*/ext-ms-*：这类名称可能是 Windows API Set 契约，不一定对应磁盘上同名的 DLL。不要看到未解析就去下载一个同名文件；先核对系统支持情况和工具分析环境。- 延迟加载和动态加载：某些依赖只有用到对应功能时才需要。Dependencies 支持静态导入等分析，但不能从文件里还原所有
LoadLibrary动态加载行为。“依赖树没报错”并不能证明运行时一定正常。
如果报错提到 VCRUNTIME 或 MSVCP，可以先检查配套的微软运行库；但也要核对程序所需的版本和架构。不要把不明来源的文件直接塞进 System32，也不要随意替换系统 DLL。
命令行：查导入和依赖链
在解压目录打开 PowerShell，先看帮助，再分析自己的文件：
.\Dependencies.exe -help
.\Dependencies.exe -imports "D:\Demo\app.exe"
.\Dependencies.exe -chain -depth 2 "D:\Demo\app.exe"-imports 查看导入信息；-chain 查看依赖链，-depth 2 限制分析深度，避免一开始就递归太多模块。以上参数按官方命令行源码核对，实际使用时也可以先运行自己下载版本的 -help。
处理完之后，保留一份修复前后的输出，并用相同启动方式和出错操作复测。工具结果用于缩小范围，最终仍以程序是否能正常运行、原始错误是否消失为准。