记一次 .NET某工控宇宙射线导致程序崩溃分析

一：背景

1. 讲故事

为什么要提 宇宙射线, 太阳耀斑 导致的程序崩溃呢？主要是昨天在知乎上看了这篇文章：莫非我遇到了传说中的bug？，由于 rip 中的0x41变成了0x61出现了bit位翻转导致程序崩溃，截图如下：

下面的评论大多是说由于 宇宙射线，这个太玄乎了，说实话看到这个 传说bug 的提法，我还是挺兴奋的，毕竟在我的分析旅程中，我也是真的遇到过，这篇就拿出来给大家分享吧，当时百思不得其解，真的是无语死了。

这位朋友找到我的时候，说程序会出现偶发性崩溃，自己在网上也发了很多帖子来寻找答案，最后都不了了之，问题确实太玄乎了，这一篇我们就开始这个奇妙之旅吧。

二：Windbg 分析

1. 为什么会崩溃

找崩溃点比较简单，使用windbg 自带的 !analyze -v 命令去挖那个 EXCEPTION_POINTERS 结构体即可。



0:083> !analyze -v

CONTEXT:  (.ecxr)

rax=0000024f82c77341 rbx=000000f275dfe7f0 rcx=00007ffb05e55658

rdx=7ffb083d8c582d89 rsi=0000000000000000 rdi=000000f275dfe300

rip=00007ffb64be082f rsp=000000f275dfeaa0 rbp=000000007ffb05ee

 r8=0000024ff9bc0810  r9=deb6f5c6f59b3377 r10=1441a86c71655650

r11=ebbed78e94800000 r12=00007ffb05e55640 r13=0000000000000020

r14=0000024b26a3d9e0 r15=0000024f82c77340

iopl=0         ov up ei ng nz na po cy

cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010a85

clr!WKS::gc_heap::background_mark_simple1+0x516:

00007ffb`64be082f 4c8b02          mov     r8,qword ptr [rdx] ds:7ffb083d`8c582d89=????????????????

Resetting default scope

EXCEPTION_RECORD:  (.exr -1)

ExceptionAddress: 00007ffb64be082f (clr!WKS::gc_heap::background_mark_simple1+0x0000000000000516)

   ExceptionCode: c0000005 (Access violation)

  ExceptionFlags: 00000001

NumberParameters: 2

   Parameter[0]: 0000000000000000

   Parameter[1]: ffffffffffffffff

Attempt to read from address ffffffffffffffff

STACK_TEXT:

000000f2`75dfeaa0 00007ffb`64be03a0     :  clr!WKS::gc_heap::background_mark_simple1+0x516

000000f2`75dfeb00 00007ffb`64be074e     :  clr!WKS::gc_heap::background_mark_simple+0x6d

000000f2`75dfeb30 00007ffb`64a45fc7     :  clr!WKS::gc_heap::background_promote+0x98

...

从卦中数据看，当前触发了后台GC，并且处于标记阶段，在标记托管堆上的对象时发现了有坏对象，无奈只能触发 CLR执行引擎异常，这也说明当前的托管堆是处于损坏状态，可以用 !verifyheap 命令验证一下。



0:083> !verifyheap

object 0000024f82c76b18: bad member 0000024F82C77F40 at 0000024F82C76B70

Last good object: 0000024F82C76AA0.

object 0000024f82c76ca8: bad member 0000024F82C77340 at 0000024F82C76CB0

Last good object: 0000024F82C76C58.

object 0000024f82c76fa8: bad member 0000024F82C77050 at 0000024F82C76FD0

Last good object: 0000024F82C76F88.

Could not request method table data for object 0000024F82C77050 (MethodTable: 00007FFB3C032138).

Last good object: 0000024F82C76FA8.

果然卦中的数据也验证了这一点，托管堆上有三个坏对象，接下来抽一个用 !do 命令来验证下。



0:083> !do 0000024f82c76b18

Name:        System.Windows.Forms.TreeNode

MethodTable: 00007ffb3c431af8

EEClass:     00007ffb3c488500

Size:        168(0xa8) bytes

File:        C:\xxxx\System.Windows.Forms.dll

Fields:

              MT    Field   Offset                 Type VT     Attr            Value Name

...

00007ffb3c431ed8  400263f       58 ....Forms.TreeNode[]  0 instance 0000024f82c77f40 children

...

0:083> !do 0000024f82c77f40

<Note: this object has an invalid CLASS field>

Invalid object

从错误信息以及刚才卦中的数据表明 TreeNode.children 内存布局被破坏了，这种情况大多是因为 MethodTable 不对了导致CLR识别不出这块内存的对象，可以用 dp 验证下。



0:083> dp 0000024f82c77f40 L4

0000024f`82c77f40  00007ffb`3c411ed8 00000000`00400008

0000024f`82c77f50  0000024f`82c56fa8 0000024f`82c57378

0:083> !dumpmt 00007ffb`3c411ed8

00007ffb3c411ed8 is not a MethodTable

从卦中的 00007ffb3c411ed8 is not a MethodTable 可以看到这个地址是错误的，那正确地址是什么呢？如果有心细的朋友会看到 !do 的时候已经显示了正确的方法表，即 00007ffb3c431ed8。

接下来仔细观察 00007ffb3c411ed8 和 00007ffb3c431ed8 这两个地址，会发现一个是 3c41 一个是 3c43，真的是无语了，截图如下：

一般来说，这种单bit位的翻转也不像是用 PInvoke 的方式让 C++ 破坏了 C# 的托管堆，也不像是什么 hook 注入导致的，反正很神奇，为了拿更多证据可以在抽一个坏对象观察下。



0:083> !do 0000024f82c76fa8

Name:        System.Windows.Forms.TreeNode

MethodTable: 00007ffb3c431af8

EEClass:     00007ffb3c488500

Size:        168(0xa8) bytes

Fields:

              MT    Field   Offset                 Type VT     Attr            Value Name

...

00007ffb3c432138  4002636       28 ...eNodeImageIndexer  0 instance 0000024f82c77050 imageIndexer

...

0:083> !do 00007ffb`3c032138

<Note: this object has an invalid CLASS field>

Invalid object

0:083> dp 0000024f82c77050 L1

0000024f`82c77050  00007ffb`3c032138

从卦中数据看：方法表 00007ffb3c032138 和 00007ffb3c432138 也是差了一个bit位，即 3c03 和 3c43 的差别。

2. 为什么会翻转

有些朋友可能说，你这数据是不是网络数据，比如有什么 纠错码，海明码 之类的，其实 mt 的数据是嵌入到 image 中的，这块数据一般在初始化的时候由 clr 构建好，后期不会有人去改写的，可以用 !address 看下。



0:083> !address 00007ffb3c432138

Usage:                  Image

Base Address:           00007ffb`3c431000

End Address:            00007ffb`3c434000

Region Size:            00000000`00003000 (  12.000 kB)

State:                  00001000          MEM_COMMIT

Protect:                00000004          PAGE_READWRITE

Type:                   01000000          MEM_IMAGE

Allocation Base:        00007ffb`3c400000

Allocation Protect:     00000080          PAGE_EXECUTE_WRITECOPY

Image Path:             C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Windows.Forms\1534a59650e0fd08da0ed8931d9f6d5f\System.Windows.Forms.ni.dll

Module Name:            System_Windows_Forms_ni

Loaded Image Name:

Mapped Image Name:

More info:              lmv m System_Windows_Forms_ni

More info:              !lmi System_Windows_Forms_ni

More info:              ln 0x7ffb3c432138

More info:              !dh 0x7ffb3c400000

Content source: 1 (target), length: 1ec8

后来计划让朋友开启 MDA 托管调试助手去验证，结果朋友给我反馈说开启后，程序运行特别慢，这个很好理解，如果你的程序 PInvoke 过多，确实容易引发过高的 GC，所以能不能适应到各位的程序，还需要实际测试。

遗憾的这条路朋友没有走通，所以寻找答案就遥遥无期了，最后也就不了了之，因为那时候我认为所有的用户态异常都是软件造成的。。。

三：总结

直到昨天看了这篇 莫非我遇到了传说中的bug？ 我现在有想法了，在下面可能的七种选项中：

宇宙射线
太阳耀斑
地磁暴
电离辐射
硬件故障
杀毒软件
内存超频

我觉得 内存超频 引发的程序不稳定概率是最大的，不知道大家可有不同的看法？