我从同事那里学到了一个很酷的生活技巧：将 .dll 文件与 Dependency Walker 关联，现在，无论何时尝试“运行” .dll 文件，它都会打开 Dependency Walker 进行分析。
问题是 Dependency Walker 有两个版本：一个 32 位，另一个 64 位。建议对 .dll 使用相同位数的版本：
是的。Dependency Walker 可与任何 32 位或 64 位 Windows 模块配合使用。Dependency Walker 有 32 位和 64 位版本。所有版本均能够打开 32 位和 64 位模块。 但是，使用 32 位 Dependency Walker 处理 32 位模块和使用 64 位 Dependency Walker 处理 64 位模块具有很大的优势。 在 64 位版本的 Windows 上运行时尤其如此，因为该版本允许执行 32 位和 64 位程序。64 位 Windows 上的 32 位子系统（称为“WOW64”）有自己的私有注册表、“AppPaths”、“KnownDlls”、系统文件夹和清单处理。只有 32 位版本的 Dependency Walker 才能访问此 32 位环境，这是准确处理 32 位模块所必需的。同样，只有 64 位版本的 Dependency Walker 才能完全访问 64 位环境，因此应始终使用它来处理 64 位模块。
有没有办法将 32 位 dll 与 32 位版本的 Dependency Walker 关联，将 64 位 dll 与 64 位版本的 Dependency Walker 关联？我对 Windows 7 或 10 的答案特别感兴趣。
答案1
为此目的创建了一个基于python的工具：https://github.com/mmatrosov/DllDispatcher
该工具非常简单。正如相应的自述文件中所述，您将 .dll 与DllDispatcher.bat文件关联，该文件调用DllDispatcher.py文件，该文件分析 .dll 内容并确定提供的 dll 是 32 位还是 64 位。然后，它会根据此情况调用提供的两个应用程序之一。应用程序的路径只是在DllDispatcher.py文件的开头进行硬编码。
我发现没有简单的方法可以确定 dll 是 32 位还是 64 位。GetBinaryType仅适用于 .exe 文件。对于 dll，应该实际加载库然后将句柄传递给IsWow64Process()，或者手动解析 dll 的标头（它具有 PE 文件格式）。我选择了后者。它的稳定性较差，但速度更快。我认为稳定性不是一个大问题，因为 PE 格式不太可能在不久的将来发生变化，并且此解决方案不必完全万无一失。