一个flash npapi插件引起的crash

这几天同事处有一个crash，表现是在chrom的 test_shell 中打开一个flash网页，而这个flash是播放了一段广告，在广播播放完毕后这个flash控件就不见了。

使用到的flash控件是npsxxx.dll 这个是一个npapi的flash插件，由于没有发生在我的电脑上，所以只能描述一下排查的过程。

首先观察了几次发现，无论是否开启appverify都是必然crash的，当然在那个特定的flash htmlpage。

crash的时候在callstack中只有一行

clientebp          

0a670098      00000000

!analyze-v 之后也只是提示你不正确的eip指针, 同事特定的汇编代码是

move [esi+14h] , xxx      

而esi是fxxxxxxx 这个一个明显不应该是应用程序可以写入的一个地址。

然后反复观察了几次发现都是这样，现在唯一的线索是clientebp    

大家知道这个childebp表达的意思应该是当前层次的callstack的ebp寄存器值，相当于也是告诉你ebp在哪里？

而由于ebp是基于stack的函数调用分层次的边界，所以我就

dds ebp  

结果看到了很多npsxxx!XX  这样的函数，也就是说在发生crash的时候ebp的信息中还是看到之前发生了很多对npsxxx这个flash插件的调用。

因此就怀疑是这个插件引起了问题，然后做了一个实验，即禁止这个插件，结果果然crash就消失了。

但是由于没有插件的符号，从callstack中得不到更加深一步的信息了。

到了这儿如何解决问题，有点头痛了。

后来，我观察childebp这个值，0a670098   ，其实这个值也是现在从crash现场能够看到的唯一值了。   

然后lm 一下，发现这个地址不属于任何模块的加载范围，也不属于任何已经卸载模块的地址范围。

!address 这个地址，发现它是一个数据地址； 且在crash时候依然有效。

由于不知道crash之前到底发生了什么，这个问题其实还是很困扰的。

不过后来的解决办法，现在想来还算不错。因为这个时候最最需要知道的就是crash前的场景，所以当时在拥有的chrome处的和插件交互的npai模块的地方大量设置了断点，最后终于找到在一个插件销毁的地方有个delete this导致了这个问题，相当于可以理解为，a 调用了b，b把a删除了，当b返回后a自己crash了。