windowsclient崩溃分析和调试

本文介绍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，找到相应的模块。偏移量。打上断点，可以在本地还原出崩溃时的运行环境。

固然，
在本地运行到相应位置时不必定崩溃，但是，有了不少其它上下文信息。可以比較easy肯定相应的C++操做。

使用IDA：
可以使用IDA让汇编代码更好看，较easy分析流程。

关闭alsr。指定建议模块载入地址：
这样可能使得更easy分析。

但是会使得安全性减小，可以用于小流量版本号。

ln指令：
windbg中ln指令可以依据地址。还原出相应的信息，比方该地址是在某个类的某个方法中。

有时可能会
还原出几个信息：A::foo() + 0x?

?, B::foo1() + 0x??。这就需要本身依据上下文推断了。

代码优化：
代码优化使得分析更难，可以尝试改变一些编译选项，减小优化级别，保留栈桢，关闭应用程序全局优化，
使得在release下的分析easy些。

所见并非真实：
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，使得调试更加easy。另外可以开多tab。而后关闭，而后再开，来測试同一个进程
有多外activex实例的状况。更进一步，可以本身调用IWebBrowser2，来模拟不少其它的状况。

np插件：
chrome中这个简单些。一个插件一个进程，多个实例。共享主线程。
还有些开源工具将activex适配为np插件，使得可以在chrome中调用ax。调试。

多机调试：
前面说过，windbg，vs都支持。

死锁：
死锁现场不会是线上问题（可以经过必定手段，使得在线上发生死锁时报告。但是基本上没用过，相应的
手段在线下有玩过）。线下问题一般会有现场，或者能拿到full dump。

通常使用windbg来看，用~*kb或者
这系列的命令看看线程都在干什么。而重点关注的则是WaitForSingleObjectEx之类的调用。

经过分析调用
相应的參数。进一步能还原出，拿到 分发器 对象后不归还的线程是谁。

或者也可以!runaway找到占用CPU 高的线程，而后看看该线程在干什么。线程循环等待，则死锁了。线程一直在那里跑，多是死循环了。 线下的死锁检測，通常可以向主线程发一个消息来实现。 warning：有可能某个线程拿到分发器对象，但是该线程已经挂掉了。