一:背景
1. 讲故事
前些天有位朋友找到我,说他的程序每次关闭时就会自动崩溃,一直找不到原因让我帮忙看一下怎么回事,这位朋友应该是第二次找我了,分析了下 dump 还是挺经典的,拿出来给大家分享一下吧。
二:WinDbg 分析
1. 为什么会崩溃
找崩溃原因比较简单,用 !analyze -v
命令观察一下便知。
从卦中数据看当前崩溃码是 c0020001,查了下码表说是 string绑定无效
,截图如下:
这看起来有点无语呀,接下来观察下线程栈。
从卦中的线程栈来看,这里利用了 Windows线程池
的timer回调,回到 clr 之后主动抛了一个异常。
2. 为什么会主动抛异常
要想知道这个答案需要分析下clr 的源码,简化后如下:
根据上面的源码,应该就是CanRunManagedCode()
函数返回false 导致的,那这个函数真的返回 false 吗?可以用 Windbg 验证下g_fForbidEnterEE 这个变量。
无语了,这个变量为true表示当前的CLR处于关闭状态,应该是主线程调用了 Exit 方法,用 windbg 可以简单验证下。
接下来研究下它要进入到什么托管方法中,这个答案就在 UMEntryThunk.m_pManagedTarget
字段里,参考源码如下:
有了这些前置知识就可以用 windbg 轻松挖掘。
通过一顿反解果然是一个托管回调函数,分析到这里ztm的开心哈,感觉马上就要看到光了,仔细找了下代码,果然是借助Windows线程池创建了一个定时事件,无语了,截图如下:
到这里就真相大白了,退出进程的时候一定要先调用C#的Dispose()
方法把非托管的Timer给关掉,否则就会出现这种偶发的崩溃异常。
3. 一些题外话
这个dump的错误码非常有误导性,一个是外部的c0020001
,一个内部的 8007042Bh
,尤其是搜内部的 8007042Bh 会把你带入到误区里,让你修复系统文件啥的,其实就是一个固定的死值,没有意义的,参见汇编代码。
所以还是多以代码说话,少道听途说陷入迷途不知返。
三:总结
说实话这个dump分析起来还是挺有难度的,需要你对Windows线程池
,clr源码实现
有一个基础了解,否则很难构造出完整证据链。