记一次 .NET某上位视觉程序离奇崩溃分析

记一次 .NET某上位视觉程序离奇崩溃分析已关闭评论
48 次浏览

A+

所属分类：.NET技术

摘要

前段时间有位朋友找到我，说他们有一个崩溃的dump让我帮忙看下怎么回事，确实有太多的人在网上找各种故障分析最后联系到了我，还好我一直都是免费分析，不收取任何费用，造福社区。

便宜好用的国外VPS推荐

一：背景

1. 讲故事

话不多说，既然有 dump 来了，那就上 windbg 说话吧。

二：WinDbg 分析

1. 为什么会崩溃

说实话windbg非常强大，双击打开dump就能第一时间帮你显示出简略的异常信息，输出如下：

 This dump file has an exception of interest stored in it. The stored exception information can be accessed via .ecxr. (bf8.5dc4): Access violation - code c0000005 (first/second chance not available) For analysis of this file, run !analyze -v clr!WKS::gc_heap::mark_object_simple1+0x220: 00007ffb`380453c4 833a00          cmp     dword ptr [rdx],0 ds:00007ffa`35451300=????????

从卦中又看到了经典的 mark_object_simple1 方法，这个方法是GC用来做对象标记之用的，所以大概率又是托管堆损坏，真是无语了，接下来用 !verifyheap 检查下托管堆。

 0:083> !verifyheap object 00000218e96963d8: bad member 00000218E9696450 at 00000218E9696420 Last good object: 00000218E96963C0. Could not request method table data for object 00000218E9696450 (MethodTable: 00007FFA35451300). Last good object: 00000218E96963D8.

一看这卦就很不吉利，真的是有对象的mt是不对的，至此我们把崩溃的直接原因给找到了。

2. 为什么对象损坏了

要找到这个答案就需要深挖 00000218e96963d8 对象，分别使用 !do 命令以及 dp 来观察内存地址。

 0:083> !do 00000218e96963d8 Name:        System.Threading.Tasks.Task+DelayPromise MethodTable: 00007ffb3542b3e8 EEClass:     00007ffb3567c7c0 Size:        120(0x78) bytes File:        C:WindowsMicrosoft.NetassemblyGAC_64mscorlibv4.0_4.0.0.0__b77a5c561934e089mscorlib.dll Fields: ... 00007ffb35451300  40035d5       48 ...m.Threading.Timer  0 instance 00000218e9696450 Timer  0:083> dp 00000218e9696450 L6 00000218`e9696450  00007ffa`35451301 00000000`00000000 00000218`e9696460  00000218`e96964c8 00000000`00000000 00000218`e9696470  00007ffb`353e4b51 00000218`e9696368

仔细观察卦中对象 00000218e9696450 所显示的mt，你会发现一个是 00007ffb35451300，一个是 00007ffa35451301，很显然前者是对的，后者是错的，可以分别用 !dumpmt 做个验证。

 0:083> !dumpmt 00007ffb35451300 EEClass:         00007ffb356942f0 Module:          00007ffb353b1000 Name:            System.Threading.Timer mdToken:         0000000002000504 File:            C:WindowsMicrosoft.NetassemblyGAC_64mscorlibv4.0_4.0.0.0__b77a5c561934e089mscorlib.dll BaseSize:        0x20 ComponentSize:   0x0 Slots in VTable: 23 Number of IFaces in IFaceMap: 1  0:083> !dumpmt 00007ffa35451301 00007ffa35451301 is not a MethodTable

细心的朋友会发现虽然两个mt地址不一样，但已经非常相近，看样子又是一例经典的bit位翻转，我去，用 .formats 转成二进制观察一下，截图如下：

记一次 .NET某上位视觉程序离奇崩溃分析

从卦中可以清晰的看到当前地址有两个 bit 的翻转，分别是第0位和第32位，接下来就要洞察为什么会有两个bit位的翻转？

3. 真的存在两个bit位翻转吗

接下来我们逐一来聊一下。

bit 0 为什么会翻转

熟悉 coreclr 底层的朋友应该知道，gc 在标记的过程中会给 mt 的第0位设置为1，表示当前对象在深度优先中已经标记过，防止重复标记，当然这个也是有源码作证的,简化后的代码如下：

 inline BOOL gc_heap::gc_mark(uint8_t* o, uint8_t* low, uint8_t* high, int condemned_gen) { 	if ((o >= low) && (o < high)) 	{ 		BOOL already_marked = marked(o); 		if (already_marked) 		{ 			return FALSE; 		} 		set_marked(o); 		 		return TRUE; 	} }  #define marked(i) header(i)->IsMarked()  BOOL IsMarked() const { 	return !!(((size_t)RawGetMethodTable()) & GC_MARKED); }

有了这段源码，这个 bit 为什么为 1 就能轻松的解释了，所以这个翻转是一个正常情况。