dependency walker（depends.exe）是用于分析windows程序依赖链的工具，红色项表示系统在所有路径中均未找到该dll，黄色项表示文件存在但存在架构不匹配或子依赖缺失，需严格匹配程序与工具的位数（x86/x64），否则导致误报。
直接拖进去看红色项，别先查路径
Dependency Walker（depends.exe）不是用来验证“文件是否存在”的，而是用来验证“加载器能否完整解析依赖链”。很多人一上来就反复确认 DLL 文件路径、权限、大小，结果浪费半小时——其实 depends.exe 打开后左树里哪个节点标红，基本就是问题所在。
操作很简单：下载对应位数的 depends22_x64.zip（Win10/11 推荐用 64 位版），解压后以管理员身份运行 depends.exe，把出问题的 .exe 或目标 .dll 直接拖进窗口。等几秒解析完成，左侧树状图里标红的模块就是缺失项。
- 红色项 = 系统在所有搜索路径里都找不到这个文件（包括它自己的子依赖）
- 黄色项 = 文件找到了，但它内部有缺失依赖，或架构不匹配（比如 32 位程序加载了 64 位 DLL）
- 灰色但带问号的项 = 延迟加载 DLL，
LoadLibrary不会报错，但首次调用函数时可能崩
注意位数匹配，x86 和 x64 版本不能混用
错误码 193（ERROR_BAD_EXE_FORMAT）和 depends.exe 里大量黄色警告，八成是位数没对齐。你用 32 位的 depends.exe 去分析一个 64 位程序，它会把所有系统 DLL 标黄，甚至假报缺失，因为根本读不到 64 位模块头。
判断方法很直接：右键点击主模块 → “Properties” → 看 “Machine Type” 是 AMD64 还是 Intel 386；再确认你运行的 depends.exe 是哪个版本。两者必须一致。
- 你的程序是 64 位 → 必须用
depends22_x64.exe - 你的程序是 32 位 → 必须用
depends22_x86.exe - 混用会导致：系统 DLL 全部标黄、依赖树不完整、误判缺失
别信“文件存在”，要看它依赖的那些是否真能加载
std::filesystem::exists("xxx.dll") == true 和 LoadLibrary("xxx.dll") != NULL 完全是两回事。前者只说明磁盘上有这个文件，后者要求该文件本身是合法 PE、位数匹配、且它导入的所有 DLL 都能被找到并加载。
常见陷阱：
- 目标 DLL 本身没问题，但它依赖的
MSVCP140.dll缺失 →depends.exe中该 DLL 会标红，而不是主程序 - 目标 DLL 依赖某个
api-ms-win-crt-*.dll→ Windows 10+ 通常由系统自动映射，depends.exe可能误标红（属已知误报，可忽略） - DLL 放在 exe 同目录，但它的依赖在
System32里是 32 位版本，而你的进程是 64 位 → 加载失败，depends.exe显示黄色警告
替代方案：Dependencies 更稳，尤其 Win10/11
原版 depends.exe 在 Win10/11 上容易卡死，特别是分析大型程序或含延迟加载的模块时。推荐改用开源替代品 DependenciesGui.exe（GitHub 上搜 Dependencies），它专为现代 Windows 优化：
- 不会无响应，支持大项目和 UWP 应用
- 明确区分“静态依赖”和“运行时动态加载”（如
LoadLibrary调用的 DLL） - 对
api-setDLL 的处理更准确，减少误报 - 界面右侧直接显示每个 DLL 的实际加载路径，一眼看出是否从预期位置加载
复杂点在于：有些 DLL 的依赖只在特定代码路径里触发，静态分析看不到。这时候得配合 Process Monitor 抓 CreateFile 事件，看 LoadLibrary 到底尝试去哪找哪些文件 —— 但绝大多数部署类问题，DependenciesGui.exe 一次拖入就能定位到根因。
