本文介绍windows上崩溃分析的一些手段,顺便提多进程调试、死锁等。
1.崩溃分析过程
1.1 确认错误码
无论是用windbg还是用vs,首先应该注意的是错误码,而90%以上的崩溃都是非法访问。
在非法访问时,可以看一下访问的目标地址。地址是0,或者离0很近(0x00000008或0xfffffffc),
一般和空指针相关。如果是一个貌似正常的地址,一般是对象已析构后访问其数据,或者堆破坏。
1.2确认崩溃对应的C++操作
什么是确认崩溃对应的C++操作:
比如非法访问,通常得有个mov指令才会触发内存访问,然后导致崩溃。而mov指针对应于C++的哪一步呢?
比如a->b->c->foo();
在看到源码时,会定位于这一行,但是,并不清楚是哪一步访问失败。所以这个时候要查看对应汇编代码。
大概会有好几个mov,简单的分析就知道是哪一步时访问失败。
对编码的影响:
这就要求,不要在单个语句中写太复杂的东西比如
x ? b[i] : y > 0 ? c->member[8] : *ptr;
这样的代码崩溃,要还原到错误的地方很难。
虚函数调用:
通常
mov edx, dword ptr [ecx]
mov edx, dword ptr [edx+0x??]
call edx
意味着虚函数调用,每一行都可能是崩溃位置(在call内崩溃时,vs会标注出下一条语句的位置)。
在第一行崩溃意味着拿到一个非法指针,可能是空,也可以指向非法地址。
在第二行崩溃意味着对象已经析构,ecx指向可以访问,但是值不对,所以拿到的虚函数表不对。
在最后一行崩溃一般还有一个崩溃栈,但是看不到栈帧,在vs中对应的栈桢显示一个地址,没其它内容。
也一般意味着对象析构。
对象及析构函数:
析构函数是经常发生崩溃的地方,如果没有用户提供的析构函数,会定位到几行汇编。所以没事,就写个
析构函数吧,至少能定位到是析构函数。
在析构函数外部还会有一大堆汇编代码,里面是对象成员析构的代码。崩溃在里面的时候,难以确认
是哪个对象析构。
如果用指针,在析构函数中主动调用Release或delete,这样可以显示调用,不用去猜是谁在析构,当然
用指针或值对象,在逻辑上各有其好处,在此不表。
如果崩溃位置是call或jmp到某个A::~A()的位置,可以猜测到析构的对象的类型是A。
对象析构顺序是从后往前,从子类到基类,根据这点,结合崩溃位置,可以猜测谁析构。
利用对象布局,比如成员在对象中的偏移,可能有得于猜测谁析构出问题。
可以人为地在对象布局中引入一些填充的字节,使得能看到this对象(线上崩溃没有堆上的数据,因为
截取fulldump并上报有操作上的难度,所以this指向堆上时可能看不到,而在栈上则有可能),有利于分析。
还原上下文:
线上拿到的dump的信息少,不能调试。所以可以根据崩溃所在模块,崩溃在模块中的偏移量,在本地
调试对应的bin,找到对应的模块,偏移量,打上断点,可以在本地还原出崩溃时的执行环境。当然,
在本地执行到对应位置时不一定崩溃,但是,有了更多上下文信息,可以比较容易确定对应的C++操作。
使用IDA:
可以使用IDA让汇编代码更好看,较容易分析流程。
关闭alsr,指定建议模块加载地址:
这样可能使得更容易分析。但是会使得安全性降低,可以用于小流量版本。
ln指令:
windbg中ln指令可以根据地址,还原出对应的信息,比如该地址是在某个类的某个方法中。有时可能会
还原出几个信息:A::foo() + 0x??, B::foo1() + 0x??,这就需要自己根据上下文判断了。
代码优化:
代码优化使得分析更难,可以尝试改变一些编译选项,降低优化级别,保留栈桢,关闭应用程序全局优化,
使得在release下的分析容易些。
所见并非真实:
windbg和vs看到的栈帧可能是假的:可能在中间某一些可能已经乱了,可能栈桢省略使得vs分析的结果不对。
(一般是vs分析得不对,另外也有windbg杯具的时候)
对于在中间已经乱掉的栈,可以根据返回地址,栈参数,栈桢省略数据等,重新还原出栈。不过在90%的情况
下,即使还原出来,也不知道下一步怎么办。
对象还原:
线上崩溃没有堆,可以将感兴趣的对象拷贝拷贝到栈上(自己得控制深拷贝),然后崩溃上报中就可以看到
对象的状态了。(注意代码优化可能使得拷贝无效)
1.3C++上的逻辑
在确定崩溃和C++操作的关系后,就是自己逻辑上的问题了,基本上能遇到的问题都是对象生命周期管理
不当,进而造成非法访问。
指针的判空能规避一处的非法访问,但是可以把错误进一步扩散。指针判空,且用且珍惜。
在设计或编码时,应当考虑代码的可调试性,比如chromium中的线程池中,添加任务时,会生成当前调用
信息,和task绑定,以使于定位错误。
1.4堆破坏
基本无解,崩溃现场和引入错误的点相差太远。只能尽人事,听天命了。
比如,开一下页堆,存在一定概率使得崩溃出现,看人品。
比如,换一个CRT堆,或者自己写个,增强错误检测。
比如,CRT本身,尤其是调试的堆,堆上有些填充信息,使得在看到的时候或多或少叹口气:大概认识这些
填充信息,想要更多的信息,难啊。。。
比如,可以自己写个调试器,自己插入页堆,或者使用系统的页堆,使得检测自动化,然后通过大规模数据
使之重现。
2.其它
多进程调试:
可以通过在
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options
建立关心的进程名的项,填上debugger键值,值为调试器路径,使得进程创建时就attach。(gflags也是
改这里)。但是问题是,有的模块是按需加载的,在这个时候还不能在对应模块中下断点。
另外可以自己在关心的位置加上MessageBox或ATLASSERT之类的代码,等弹出对话框时再attach到对应进程。
activex:
attach方法同理。但是,IE的多进程模型会使得attach不方便。
在IE9及以上,其进程模型是一个主进程,控制多个tab进程,按一定规则创建tab进程,将任务分派到
tab上。同一个网页打开两次,可能分配到不同的进程上,也可能是相同的进程。在同一个进程中,同一
个activex可能有多个实例,而且每个实例对应的主线程还不一定是同一个线程。
一般会控制只开一个tab,使得调试更加容易。另外可以开多tab,然后关闭,然后再开,来测试同一个进程
有多外activex实例的情况。更进一步,可以自己调用IWebBrowser2,来模拟更多的情况。
np插件:
chrome中这个简单些。一个插件一个进程,多个实例,共享主线程。
还有些开源工具将activex适配为np插件,使得可以在chrome中调用ax,调试。
多机调试:
前面说过,windbg,vs都支持。
死锁:
死锁现场不会是线上问题(可以通过一定手段,使得在线上发生死锁时报告,但是基本上没用过,对应的
手段在线下有玩过)。线下问题一般会有现场,或者能拿到full dump。一般使用windbg来看,用~*kb或者
这系列的命令看看线程都在干什么。而重点关注的则是WaitForSingleObjectEx之类的调用。通过分析调用
对应的参数,进一步能还原出,拿到 分发器 对象后不归还的线程是谁。或者也可以!runaway找到占用CPU
高的线程,然后看看该线程在干什么。线程循环等待,则死锁了。线程一直在那里跑,可能是死循环了。
线下的死锁检测,一般可以向主线程发一个消息来实现。
warning:有可能某个线程拿到分发器对象,但是该线程已经挂掉了。
作者:baihacker 发表于2014-7-30 23:01:27 原文链接
阅读:138 评论:0 查看评论