windows客户端崩溃分析和调试

本文介绍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：有可能某个线程拿到分发器对象，但是该线程已经挂掉了。