目录
3.1、使用Dependency Walker打开软件主程序，查看库与库的依赖关系，找出出问题的库
VC++常用功能开发汇总（专栏文章列表，欢迎订阅，持续更新...）
https://blog.csdn.net/chenlycly/article/details/124272585C++软件异常排查从入门到精通系列教程（专栏文章列表，欢迎订阅，持续更新...）https://blog.csdn.net/chenlycly/article/details/125529931C++软件分析工具从入门到精通案例集锦（专栏文章正在更新中...）https://blog.csdn.net/chenlycly/article/details/131405795C/C++基础与进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html开源组件及数据库技术（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_12458859.html网络编程与网络问题分享（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_2276111.html 安装了新版本的安装包之后，启动程序时会报错，导致程序启动失败。这是日常工作中比较常见的一类问题，本文详细讲述如何使用PE信息查看工具和Dependency Walker工具去分析这类问题的完整过程，给大家提供一个借鉴或参考。
1、问题说明
测试同事安装新版本的安装包之后，一启动程序就会报错，弹出如下的报错提示框：
导致程序启动失败。提示无法在xxsysctrldll.dll库中找不到InitMtDsc接口，这是一类比较常见的问题，一般都是因为主程序中有dll库的版本不一致引起的。比如A.dll依赖了B.dll库，出现接口找不到的问题，可能的原因有：
1）B.dll中的function接口不存在或者已经被删除了。比如老版本的A.dll和新版本的B.dll混在一起使用，老版本A.dll调用了function接口，但该接口在新版本的B.dll中已经删除或者已经更改名称了，所以会出现找不到接口的问题。比如新版本的A.dll和老版本的B.dll混在一起使用，新版本的A.dll调用了新版本的B.dll中新增的接口，但当前软件打包的还是老版本的B.dll，所以程序运行时在老版本B.dll中找不到接口。
2）B.dll中的function接口参数修改了。C++中支持函数重载（函数名称一样，但参数不一样），在编译时默认情况下会对函数名称进行改编，在生成的函数符号中融入了参数信息，比如上面截图中的 ?lnitMtDsc@@YAXGH@Z。
在B.dll中的function接口还在，但是参数修改了，函数符号发生了变化，所以找不到了。
在这里，给大家重点推荐一下我的几个热门畅销专栏：
专栏1：（该专栏订阅量接近350个，有很强的实战参考价值，广受好评！专栏文章持续更新中，预计更新到200篇以上！）
C++软件调试与异常排查从入门到精通系列文章汇总https://blog.csdn.net/chenlycly/article/details/125529931
本专栏根据近几年C++软件异常排查的项目实践，系统地总结了引发C++软件异常的常见原因以及排查C++软件异常的常用思路与方法，详细讲述了C++软件的调试方法与手段，以图文并茂的方式给出具体的实战问题分析实例，带领大家逐步掌握C++软件调试与异常排查的相关技术，适合基础进阶和想做技术提升的相关C++开发人员！
专栏中的文章均是通过项目实战总结出来的（通过项目实战积累了大量的异常排查素材和案例），有很强的实战参考价值！专栏文章还在持续更新中，预计文章篇数能更新到200篇以上！
专栏2：
C/C++基础与进阶（专栏文章，持续更新中...）https://blog.csdn.net/chenlycly/category_11931267.html
以多年的开发实战为基础，总结并讲解一些的C/C++基础与进阶内容，以图文并茂的方式对相关知识点进行详细地展开与阐述！专栏涉及了C/C++领域的多个方面的内容，同时给出C/C++及网络方面的常见笔试面试题，并详细讲述Visual Studio常用调试手段与技巧！
专栏3：
开源组件及数据库技术https://blog.csdn.net/chenlycly/category_12458859.html
以多年的开发实战为基础，分享一些开源组件及数据库技术！
2、问题分析思路
对于上述这类问题，基本就是库的版本不一致导致的，具体是哪个库的版本有问题，我们使用PE信息查看工具和Dependency Walker工具就能快速排查出来。
先使用Dependency Walker打开exe主程序，查看库与库的依赖关系，比如：
确定问题出在哪些个库中，同时可以进一步的确定是找不到库，还是调用的接口在目标dll库中找不到，亦或是要调用的接口在目标dll库中修改了参数。
然后使用PE信息查看工具打开出问题的dll库文件，查看库文件的时间戳，比如：
即库文件（二进制文件）的编译生成时间，这样我们就能确定到底是哪个库的版本不对了。
另外，在这个分析过程中，我们可能需要在svn或git上查看库文件的发布记录，和相关模块开发维护团队确认库与库之间的版本对应关系。
3、问题分析过程
3.1、使用Dependency Walker打开软件主程序，查看库与库的依赖关系，找出出问题的库
首先我们使用Dependency Walker打开软件的exe主程序，查看库与库之间的依赖关系，看看问题具体出在哪些库中。
Dependency Walker打开exe主程序后，会以树状结构将exe主程序依赖的库以及这些库依赖的其他库展示出来。默认情况下，会自动将树中的节点全部展开。
注意一下，当前最新的Dependency Walker还是2016年的，当运行在Win10等新的系统中时，打开文件可能会比较慢，甚至要等好几分钟才能打开完成。要稍微耐心等待一下。
在展开的树中，节点太多，除了软件的业务库，还包含大量的Windows系统库，为了方便查看，我们可以将系统库的节点给折叠起来。这就要求我们要识别出来哪些库是系统库，比如常见的user32.dll、ntdll.dll、kernel32.dll，还有以API-MS-WIN开头的系统库：
这对于经常搞Windows软件开发的人很简单，但对于新手或者不熟悉Windows软件开发的人来说，可能很难分辨。
在Dependency Walker中，如果库找不到或者库中的接口有问题，问题节点前面会显示特别的异常图标：
1）在运行的机器中找不到某个库，会在该库的节点前显示一个黄色的问号图标，如下所示：
这可能是打包软件时，没有将程序依赖的库打包进安装包中。比如忘记将一个新增的dll库打包到安装包中、没有将运行时库打包到安装包中。注意，不同版本的Visual Studio使用的运行时库名称是不一样的，比如Visual Studio 2010的运行时库是msvcr100.dll和msvcp100.dll，Visual Studio 2017的运行时库是msvcp140.dll、vcruntime140.dll和ucrtbase.dll（不再有msvcr140.dll、新增了vcruntime140.dll和ucrtbase.dll）。
使用Visual Studio编译出来的程序，在打安装包时都需要把对应版本的运行时库打包进去。关于不同Visual Studio版本对应的运行时库的详细说明，可以参见我的文章：使用Dependency Walker和Process Explorer排查程序启动时缺少ucrtbase.dll等运行时库以及报0xC000007B错误
2）在某个库中找不到调用的接口，会在对应的接口行前面显示一个红色的图标，如下所示：
可能这个接口在库中已经不存在了（被删除了），也可能是接口的参数修改了，生成的函数符号变了。
在本案例中，最开始启动程序报错的截图如下：
从这个截图可以看出，问题与xxsysctrldll.dll库有关。用Dependency Walker打开exe主程序后，显示出问题的两个库的截图如下所示：
首先看到xxsysctrldll.dll依赖了xxdscdll.dll，之所以依赖，肯定是xxsysctrldll.dll库中调用了xxdscdll.dll库中的接口。然后我们看到xxdscdll.dll节点前面有淡红色的异常图标，所以我们点击xxdscdll.dll节点，此时右边实现两块信息，上面PI部分是依赖该库的xxsysctrldll.dll从该库中引入了哪些接口，即xxsysctrldll.dll库中调用了xxdscdll.dll库中的那些接口；下面的E部分，是当前xxdscdll.dll库有哪些导出接口。
关于导出导入，对于dll动态库本身，接口是导出的，是要提供给其他库调用的；对于使用到该库的其他库，需要引入当前库的接口，然后调用这些接口的。一般可以使用#import导入dll库对应的.lib库，比如#pragma comment( lib, "winmm.lib" ) ，这个是在编译链接时会用到，如果找不到调用的接口符号，则会编译报错。接口的运行调用则时发生在程序运行阶段的。
看到导入列表中的接口?InitMtDsc@@YAXGH@Z（这是经过编译器名称改编后的函数名称，带了参数信息）所在行前面显示了红色的图标，应该是该接口符号，在当前的xxdscdll.dll中没有。可以翻看下方的xxdscdll.dll的导出函数列表，看看xxdscdll.dll有没有导出InitMtDsc接口。在xxdscdll.dll导出接口的列表中确实找到了InitMtDsc接口，但包含了参数信息的改编后的名称是不一样的，即?InitMtDsc@@YAXG@Z，所以应该是该接口的参数修改了。
目前可以确定是xxdscdll.dll与xxsysctrldll.dll两个库不匹配，但具体是哪个库有问题，还是看这两个库的时间戳（库的编译生成时间）。
3.2、使用PE工具查看dll库的时间戳
此时我还要使用到PeViewer PE信息查看工具。打开PeViewer工具，点击打开按钮，找到xxdscdll.dll与xxsysctrldll.dll文件的路径，打开文件查看到文件的时间戳：（点击左侧列表中的头部 -> NT头 -> 文件头，右侧就会显示文件的时间戳）
从上图中可以看到，xxdscdll.dll库的时间戳为2023/12/07[04:29:53]，xxsysctrldll.dll库的时间戳为2023/12/15[15:29:37]。
我这边经常使用的PE信息查看工具叫PeViewer，以前排查问题时，用该工具打开64位二进制文件发生了闪退。后来在网上搜到了MiTeC EXE Explorer工具，这个工具兼容性比较好，打开64位二进制文件没有问题。大家后面遇到问题时，可以使用更强大的MiTeC EXE Explorer。
最近底层的组件有多个模块有改动，12月15日有发布新库过来，查看了svn上的发布记录：
发布说明中提及到的发布模块中有提到xxdscdll模块和xxsysctrldll模块，但实际上并没有发布库文件xxdscdll.dll，xxsysctrldll.dll库文件发布过来了。所以结合上面的PE工具查看的时间戳，xxsysctrldll.dll是最新版本，但xxdscdll.dll是老版本。
那明明发布说明中指出要发布xxdscdll模块过来，为啥没发布成功呢？先到文件服务器上查看编译日志，看看是不是xxdscdll模块代码编译失败了。经查看，xxdscdll模块编译没有错误的，文件有生成的。于是找了一下配置管理员，他查看了一下发布模块配置，发现了问题：
在配置发布模块xxdsc的名称时，错误地将xxdscdll.dll写成了xxdssdll.dll（将dsc写成dss），导致了自动执行发布脚本时没有拷贝xxdscdll.dll到指定产品的代码流上。
3.3、解决办法
所以在该问题场景中，新版本的xxsysctrldll.dll使用了老版本的xxdscdll.dll，新版本的xxsysctrldll.dll调用了新版本的xxdscdll.dll中的InitMtDsc接口，在新版本的xxdscdll.dll中修改了InitMtDsc接口的参数，即新版本的xxdscdll.dll调用了修改参数后的InitMtDsc接口，所以在老版本的xxdscdll.dll中找不到修改参数后的InitMtDsc接口，所以程序启动时弹出了文章最开始说到的错误提示框：
解决办法很简单，只需要将漏发的xxdscdll.dll文件发布过来就好了。
4、最后
本案例中详细介绍了如何使用PE信息查看工具与Dependency Walker去排查程序启动报错的问题，希望能给大家提供一定的借鉴或参考。