[原]调试实战——使用windbg调试崩溃在ole32!CStdMarshal::DisconnectSrvIPIDs
前言
最近程序会不定期崩溃,很是头疼!今晚终于忍无可忍,下决心要干掉它!从之前的几个相关的dump
可以猜到是有接口未释放导致的问题,但没有确认到底是哪个接口。本篇总结记录了找到这个接口的过程。
{% note info %}
这是几年前在项目中遇到的一个问题。我对之前的笔记进行了整理重新发布于此。
{% endnote %}
初识问题
用windbg
打开dump
文件,显示如下:
![startup startup](./images/startup.png)
从图中可以很明显的看出来是访问违例(因为红框标识的地址5bbc97f8
的内容是????????
),而且这是一条call
指令,call
调用的地址存储在ecx+8
(0x5bbc97f8
) 处。我们可以用!address address
来查看某个地址的信息,输入!address 5bbc97f8
![address info address info](./images/address-info.png)
从图中得知,地址5bbc97f8
对应的内存已经被释放了(State
是 MEM_FREE
)。windbg
还贴心的给出了和此地址相关的一些模块信息。其中有几个是我们自己的模块,从Unloaded
可以看出这几个模块曾经被卸载过。很有可能跟我们的崩溃相关。
至此,我们可以大胆猜测崩溃的原因是模块被卸载后,还要执行其中的代码!:bomb:
下面让我们继续分析,为什么模块卸载后还会执行其中的代码!
寻根溯源
先用.ecxr
切换到发生异常时的上下文,然后用kpn
(k
显示调用栈,p
显示函数的参数,n
显示栈帧编号)查看调用栈,如下图:
![ecxr-kpn ecxr-kpn](./images/ecxr-kpn.png)
从上图可知,11
号线程在调用CoUninitialize()
执行COM
的线程清理工作,frame 0
在调用ole32!CStdMarshal::DisconnectSrvIPIDs()
时崩溃了!从Disconnect
猜测是要断开连接!使用ub 76f8bbe7
(76f8bbe7
是由76f8bbe4
+ 3
得到的,在上一篇文章里介绍过了)查看崩溃前的几条指令:
![ub-76f8bbe7 ub-76f8bbe7](./images/ub-76f8bbe7.png)
红框内的指令非常像是虚函数的调用(调用约定是stdcall
,不是thiscall
) eax
是调用类对象的指针(通过入栈方式传递), ecx
指向虚函数表(vtable
),dword ptr[ecx+8]
是虚函数表中的第三项(32
位下指针占4
字节,第一项的偏移是+0
,第二项的偏移是+4
,第三项的偏移是+8
)。回想IUnkown
的前三个函数分别是QueryInterface()
, AddRef()
和 Release()
,可以大胆猜测这里是在调用Release()
,跟上下文也很搭(从CoUninitialize()
推断当前线程正在做COM
清理工作)!我们的猜测很有可能是正确的!
我们先小小总结一下:整个过程应该是这样的,我们使用了一个COM
接口,但是由于某些原因并没有释放,线程在退出的时候,调用CoUninitialize()
做COM
清理工作。当清理到我们的接口的时候,由于接口代码所在的dll
已经被卸载了,从而导致了访问违例!下面我们的任务是找出到底是哪个接口没释放,然后对照代码验证我们的猜测是否正确!
验证
先用lm a 5bbc97f8
确认下该地址属于哪个模块。
![lma-5bbc97f8 lma-5bbc97f8](./images/lma-5bbc97f8.png)
看来,地址5bbc97f8
落在AccIME.dll
中,由于AccIME.dll
已经被卸载了,我们需要使用命令.reload /f AccIME.dll=5bbb0000,5bbd8000-5bbb0000
来重新加载已经被卸载的模块,我们可以使用lm vm AccIME
来确认加载成功与否。
![reload-and-lmvm reload-and-lmvm](./images/reload-and-lmvm.png)
从上图可知,我们成功的加载了AccIME
模块,符号也加载成功了。
**友情提示:**如果遇到如下错误,说明我们成功加载了被卸载的dll
,但是加载符号的时候遇到了问题。
![reload-failed reload-failed](./images/reload-failed.png)
可以使用!sym noisy
开启嘈杂模式,然后再次执行.reload
命令,通过输出日志来排查具体原因。排查完毕后可以使用!sym quiet
来关闭嘈杂模式。具体使用方法可通过.hh !sym
查看windbg
帮助文档。
接下来我们用ln 5bbc97f8
查一下该地址附近函数。
![ln-5bbc97f8 ln-5bbc97f8](./images/ln-5bbc97f8.png)
至此,我们可以看到是与AccIME!CCfgDpyScheme
类相关的问题,接下来我们可以把重点放到对此类的引用计数的使用上了!
本篇总结暂时写到这,还需要弄明白几个问题:
- 涉及引用计数的相关代码是否有问题。
- 为什么有时候会崩溃,有时候不崩溃。
有结果后会再发一篇总结,敬请期待!(能力有限,没能查出来:cry:)
解决方案
由于没能查出代码哪里有问题。使用临时解决方案先绕过去了:在退出的时候,没有使用FreeLibrary()
显示卸载该模块,交由操作系统来做模块清理工作)。
未弄明白的问题的可能原因:
-
涉及引用计数的相关代码是否有问题。
Oops, 没查出代码哪里有问题。无法确定问题的根本原因。:sob:
-
为什么有时候会崩溃,有时候不崩溃。
有时候崩溃
应该是还没断开连接,对应的dll
就被卸载了。有时候不崩溃
应该是在卸载dll
之前,已经成功的断开了连接。
命令总结
-
!address address
可以查看对应地址的信息,如果一个地址不可访问,那么显示的内容会是????????
。 -
.ecxr
可以让windbg
使用发生异常时的上下文,这样再使用k
等命令时就是发生异常时的相关信息了。 -
u
可以反汇编某个地址对应的代码,ub
可以向前反汇编,b
应该是backward
的缩写。 -
lm a address
可以查看address
所属的模块。 -
ln
可以查看某个地址附近的符号名。 -
.reload /f <image.ext>=<base>,<size>
可以加载模块(甚至是已卸载的)到base
指定的位置,并为之加载符号。 -
关于各个
windbg
命令的用法,可以使用.hh command
进行查看!非常方便,而且非常重要!
参考资料
- 《格蠹汇编》
windbg
帮助文档