目录
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工具去分析这类问题的完整过程,给大家提供一个借鉴或参考。
? ? ? ?测试同事安装新版本的安装包之后,一启动程序就会报错,弹出如下的报错提示框:
导致程序启动失败。提示无法在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
以多年的开发实战为基础,分享一些开源组件及数据库技术!?
? ? ? ?对于上述这类问题,基本就是库的版本不一致导致的,具体是哪个库的版本有问题,我们使用PE信息查看工具和Dependency Walker工具就能快速排查出来。
? ? ? ?先使用Dependency Walker打开exe主程序,查看库与库的依赖关系,比如:
确定问题出在哪些个库中,同时可以进一步的确定是找不到库,还是调用的接口在目标dll库中找不到,亦或是要调用的接口在目标dll库中修改了参数。
? ? ? ?然后使用PE信息查看工具打开出问题的dll库文件,查看库文件的时间戳,比如:
即库文件(二进制文件)的编译生成时间,这样我们就能确定到底是哪个库的版本不对了。
? ? ? ?另外,在这个分析过程中,我们可能需要在svn或git上查看库文件的发布记录,和相关模块开发维护团队确认库与库之间的版本对应关系。
? ? ? ?首先我们使用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错误https://blog.csdn.net/chenlycly/article/details/131505299此外,很多系统库节点前面也会显示一个黄色的问号图标,这些系统库一般可以忽略掉,不用管。
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两个库不匹配,但具体是哪个库有问题,还是看这两个库的时间戳(库的编译生成时间)。
? ? ? ?此时我还要使用到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到指定产品的代码流上。
? ? ? ?所以在该问题场景中,新版本的xxsysctrldll.dll使用了老版本的xxdscdll.dll,新版本的xxsysctrldll.dll调用了新版本的xxdscdll.dll中的InitMtDsc接口,在新版本的xxdscdll.dll中修改了InitMtDsc接口的参数,即新版本的xxdscdll.dll调用了修改参数后的InitMtDsc接口,所以在老版本的xxdscdll.dll中找不到修改参数后的InitMtDsc接口,所以程序启动时弹出了文章最开始说到的错误提示框:
解决办法很简单,只需要将漏发的xxdscdll.dll文件发布过来就好了。
? ? ? ?本案例中详细介绍了如何使用PE信息查看工具与Dependency Walker去排查程序启动报错的问题,希望能给大家提供一定的借鉴或参考。