消息id重复引发的内存读取异常问题

1、引言

      本文就最近遇到的一个异常崩溃实例，详细介绍了使用Windbg分析问题和解决问题的过程。另外，本文主要讲解dump的静态分析，至于将Windbg动态挂载到目标进程中去动态调试的内容，不是本文讲解的范畴，如需了解，可查阅本专栏中相关的文章。

2、问题描述

       最近两天软件频繁的出现崩溃，崩溃的上下文都是一样的，我在看其他问题时也遇到过两次。据负责异常分析的同事说，是底层的组件层回调的一个消息携带的数据的内存地址有问题，导致上层在处理这个消息时产生了崩溃，这个问题已经交由组件层去跟踪排查。因为崩溃比较频繁，想看一下到底是怎么回事，于是向负责异常分析的同事要来dump文件，分析一下看看情况。

3、windbg的初分析

       拿来dump文件，找到对应版本的pdb文件，用windbg打开dump文件，使用.excr命令切换到异常上下文，找到最后执行的以后一条汇编（引起崩溃的那条汇编指令）：

这显然又是访问了很小的属于64KB NULL指针内存区的地址，这个NULL指针内存区是禁止访问的，所以产生了异常。遇到这种情况，我们的第一反应是，切换到堆栈的第一帧，查看异常所在的函数中变量的值是否有异常：

 点击上图中的第一帧，可以看到如下的局部变量：

对照这一帧对应的C++函数：
 

如上面可以看出，传进来的wParam参数值为1，上述函数中会将1作为地址，强转成TMTSecDynPwdCerRet_Api结构体指针，然后就崩溃在接下来的对结构体成员bLocal的访问上，因为bLocal是结构体TMTSecDynPwdCerRet_Api的第一个成员，如下：

如果结构体指针地址为1，则bLocal成员的内存地址就是0x00000001，上面的函数中要判断bLocal成员是否为TRUE，就会访问到0x00000001内存地址，这样就出现了windbg中执行异常的汇编指令：

根据C++代码，进入到上述的异常所在的函数OnDynamicPwdResult，是mtclib层投递MTC_UI_DYN_PWD_FIN触发的，如下：
 

再往下，最终是组件层投递上来的消息触发的。咋一看，貌似是组件层投递上来的消息有问题，即回调上来消息里携带的数据地址有问题（地址为0x00000001），这个问题应该交给组件层来跟踪就可以了。问题到此就结束了？我还是想到我们的库中去看一看。

 4、进一步分析

       到我们的下层库中，查看向UI投递MTC_UI_DYN_PWD_FIN消息的地方：

立马看出不对劲的地方，如果是终端组件层回调上来的数据地址（wParam）有问题，那上面的函数也强转成了TMTSecDynPwdCerRet_Api结构体指针，在打印日志时，也访问了结构体成员bLocal，应该立即会崩溃在mtclib层，怎么会跑到UI层才崩溃呢？由此可以看出，很可能不是终端组件层的问题，而是我们上层自己的问题。于是想到，是不是两个消息id重复了，混合交叉出的问题。于是Go到消息MTC_UI_DYN_PWD_FIN定义的地方，果然看到了假定的异常：
 

是后来新增加的两条消息MTC_UI_NEED_DYN_PWD、MTC_UI_DYN_PWD_FIN位置放错了，应该放到MTC_UI_MCONF_MSG_END的前面去，如果按上图的位置，那MTC_UI_DYN_PWD_FIN消息号就和MTC_UI_LIVE_LOGIN_FAILED消息号一样了。根据实际场景分析，底层投递的应该是MTC_UI_LIVE_LOGIN_FAILED消息，因为消息id相等，到上层后被当成MTC_UI_DYN_PWD_FIN消息处理了，所以出现了最开始的异常。

       上述两个消息是新人添加的，由于对现有代码不熟悉，不了解代码中的相关约定，所以导致了上述异常的产生。

5、结束语

       遇到问题时，我们还是要尽可能多的去看看细节，多去深入的去了解一些细节，往往问题就出现在某个细节上。有细节有真相！