我构建了一个动态链接到多个 DLL 的可执行文件。其中大部分默认安装在 Windows 上，但版本可能略有不同。其他的我随应用程序分发，但它们可能又依赖于其他 DLL。
如果我在本地运行可执行文件并收到 Windows 错误消息“无法加载 [whatever]。应用程序配置不正确”，这似乎意味着缺少“whatever”所依赖的库。但它(相当令人恼火)忽略了准确指定它在加载时遇到问题的 DLL。有时我可以使用 Dependency Walker 来解决这个问题查看是否有明显缺失的库。其他时候，我可以诉诸 Process Monitor这可以告诉我 Windows 在发出错误消息之前正在寻找哪个文件。
但是，当最终用户尝试诊断他们的问题时，这些并不是最终用户必须使用的合理工具。有什么方法可以让 Windows 准确地说出它在解析时遇到问题的库，以便可以将其输出到日志或显示在消息框中？
最佳答案
根据我的经验，此类错误的一个常见原因是意外运送了一个链接到 C 运行时调试版本的组件，该版本明确不可再分发，因此只有在最终用户的系统上，如果他们碰巧安装了匹配版本的 VisualStudio。它的名称类似于 MSVCR80D.DLL 而不是 MSVCR80.DLL。
Dependency Walker 无疑是开发人员用来检查可执行文件的正确工具。它可以 Hook 应用程序以获取 DLL 加载事件并运行它，因此您可以发现在运行时动态加载的 DLL 以及在构建时命名的 DLL。
Dependency Walker 也是可编写脚本的，并且可以写入日志文件。我将这种方式用作构建过程的一部分，以在打包发布之前验证发货。我将所有要传送的文件暂存到它们传送的目录树的模型中。我使用 dependency walker 托管的应用程序 Debug模式，使其加载所有可选的点点滴滴，然后退出。 Depends.exe 给我留下了一个很好的日志文件，我用 Perl 脚本检查它，如果从系统上的任何地方加载任何 DLL 而不是 \WINDOWS 或暂存区域，或者如果一个加载了意外版本或调试版本的 C 运行时。只有在检查成功后，我才会构建将要发布的 InnoSetup 安装程序包。这已经避免了几次尴尬，并且非常值得为弄清楚该怎么做而付出的努力。
如果您知道每个 DLL 要么是“官方”Windows DLL 要么是您发货的一部分，那么您就很有可能在客户的机器上正常工作。
编辑: Dependency Walker 的官方主页是个四处闲逛的好地方。那里提供的版本可能比 MSVS 附带的版本更新，并且有大量关于高级用途的不错的文档。
我可以确认我已经在 depends.exe 下运行了 IE，但根本没有进行太多测试。
关于windows - 在最终用户系统上调试 "application configuration is incorrect"问题的好方法？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3178729/