记一次 .NET某汗液测试机系统 崩溃分析

一：背景

1. 讲故事

上个月在社区写的文章比较少，一直关注的朋友应该知道那段时间被狗咬了以及一些琐事处理，所以手头上也攒了不少需要分享的案例，这段时间比较空闲，逐个给大

家做个分享吧，刚好年后为新版的 .NET高级调试训练营 做案例储备，所以抓紧时间疯狂输出吧！

这次生产事故的dump是训练营里一位朋友给到我的，由于朋友没有分析出来，让我帮忙看看，毕竟我的修车经验相对来说更丰富一些，算是他们背后坚实的保障吧，话不多说上windbg说话。

二：WinDbg分析

1. 为什么会崩溃

由于windbg默认自动定位到崩溃的线程，而崩溃的dump重点是观察它的崩溃前上下文，这里使用 .ecxr 和 k 命令，输出参考如下：

0:000> .ecxr
eax=00000000 ebx=4d6d8360 ecx=00000003 edx=00000000 esi=4d6f0ca0 edi=4d6f0c74
eip=71a567c7 esp=026fd834 ebp=026fd83c iopl=0         nv up di pl nz na po nc
cs=0000  ss=0000  ds=0000  es=0000  fs=0000  gs=0000             efl=00000000
System_Windows_Forms_ni!System.Windows.Forms.ImageList.ImageCollection.SetKeyName+0x1b:
71a567c7 cc              int     3

0:000> k
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr
00 026fd83c 0c2c4e7e     System_Windows_Forms_ni!System.Windows.Forms.ImageList.ImageCollection.SetKeyName+0x1b
01 026fe474 0c2c063b     xxx!xxx.MainForm.InitializeComponent+0x198e
02 026fe488 095cb9de     xxx!xxx.MainForm..ctor+0x5fb
03 026fe4e4 0da5bc7a     xxx!xxx.LoginForm.button_OK_Click+0x52e
04 026fe4f8 71a38bdf     xxx!xxx.LoginForm.LoginForm_Load+0x9a
05 026fe528 710b325a     System_Windows_Forms_ni!System.Windows.Forms.Form.OnLoad+0x2f
...

从卦象看是崩溃在 System.Windows.Forms.ImageList.ImageCollection.SetKeyName 方法上，很显然这个方法属于微软的SDK底层库，不管怎么说是一个托管异常，既然是托管异常我们可以用 !t 观察到具体的崩溃信息。

0:000> !t
ThreadCount:      26
UnstartedThread:  0
BackgroundThread: 12
PendingThread:    0
DeadThread:       13
Hosted Runtime:   no
                                                                         Lock
       ID OSID ThreadOBJ    State GC Mode     GC Alloc Context  Domain   Count Apt Exception
   0    1  534 0299e700     a6028 Preemptive  4D6F0EFC:00000000 02997bd0 0     STA System.IndexOutOfRangeException 4d6f0ca0
   2    2  5b4 029af278     2b228 Preemptive  00000000:00000000 02997bd0 0     MTA (Finalizer)
   3    6  ff0 02a60eb0   102a228 Preemptive  00000000:00000000 02997bd0 0     MTA (Threadpool Worker)
   ...

0:000> !pe
Exception object: 4d6f0ca0
Exception type:   System.IndexOutOfRangeException
Message:          Index was outside the bounds of the array.
InnerException:   <none>
StackTrace (generated):
    SP       IP       Function
    026FD834 71A567C7 System_Windows_Forms_ni!System.Windows.Forms.ImageList+ImageCollection.SetKeyName(Int32, System.String)+0x33e157

StackTraceString: <none>
HResult: 80131508

从卦象看非常奇怪，怎么底层库中抛了一个数组索引越界异常？难道是底层的bug？一般来说这些代码都是铜墙铁壁，固若金汤，坚如磐石，稳如泰山，无懈可击，不可能有如此低级的bug。。。

2. 真的是底层库bug吗？

要想寻找答案，可以根据线程栈上的函数寻找底层源码，从源码上寻找答案，修剪后的代码如下：

        private void InitializeComponent()
        {
            this.imageList_btnbg.ImageStream = (System.Windows.Forms.ImageListStreamer)resources.GetObject("imageList_btnbg.ImageStream");
            this.imageList_btnbg.TransparentColor = System.Drawing.Color.Transparent;
            this.imageList_btnbg.Images.SetKeyName(0, "normal-main.bmp");
            this.imageList_btnbg.Images.SetKeyName(1, "focus-main.bmp");
            this.imageList_btnbg.Images.SetKeyName(2, "select-main.bmp");
            this.imageList_btnbg.Images.SetKeyName(3, "gray-main.bmp");
            this.imageList_btnbg.Images.SetKeyName(4, "down_1.png");
            this.imageList_btnbg.Images.SetKeyName(5, "down_2.png");
            this.imageList_btnbg.Images.SetKeyName(6, "down_3.png");
            this.imageList_btnbg.Images.SetKeyName(7, "up_1.png");
            this.imageList_btnbg.Images.SetKeyName(8, "up_2.png");
            this.imageList_btnbg.Images.SetKeyName(9, "up_3.png");
        }

        public void SetKeyName(int index, string name)
        {
            if (!IsValidIndex(index))
            {
                throw new IndexOutOfRangeException();
            }
            if (imageInfoCollection[index] == null)
            {
                imageInfoCollection[index] = new ImageInfo();
            }

            ((ImageInfo)imageInfoCollection[index]).Name = name;
        }

        private bool IsValidIndex(int index)
        {
            if (index >= 0)
            {
                return index < Count;
            }
            return false;
        }

        public int Count
        {
            get
            {
                if (owner.HandleCreated)
                {
                    return SafeNativeMethods.ImageList_GetImageCount(new HandleRef(owner, owner.Handle));
                }
                int num = 0;
                foreach (Original original in owner.originals)
                {
                    if (original != null)
                    {
                        num += original.nImages;
                    }
                }
                return num;
            }
        }

        [Browsable(false)]
        [EditorBrowsable(EditorBrowsableState.Advanced)]
        [DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)]
        [SRDescription("ImageListHandleCreatedDescr")]
        public bool HandleCreated => nativeImageList != null;

仔细通读卦中的代码逻辑，看样子是 IsValidIndex()=false 导致的手工 IndexOutOfRangeException 异常，而 IsValidIndex()=false 是由于 index < Count 的条件成立，后面的 Count 是取自 ImageList_GetImageCount 或者 owner.originals 值。

代码逻辑我们是分析清楚了，接下来就是看汇编来分析下这个dump的现状，入手点就是从 index 值入手，即对 InitializeComponent() 方法进行反汇编。

0:000> !clrstack
OS Thread Id: 0x534 (0)
Child SP       IP Call Site
026fd784 771316bc [HelperMethodFrame: 026fd784]
026fd834 71a567c7 System.Windows.Forms.ImageList+ImageCollection.SetKeyName(Int32, System.String)
026fd848 0c2c4e7e xxx.MainForm.InitializeComponent()
026fe47c 0c2c063b xxx.MainForm..ctor()
026fe490 095cb9de xxx.LoginForm.button_OK_Click(System.Object, System.EventArgs)
...

0:000> !U /d 0c2c4e7e
Normal JIT generated code
xxx.MainForm.InitializeComponent()
Begin 0c2c34f0, size 5ded
...
0c2c4e62 e8d9b5d864      call    System_Windows_Forms_ni+0x160440 (71050440) (System.Windows.Forms.ImageList.get_Images(), mdToken: 06002599)
0c2c4e67 898514f5ffff    mov     dword ptr [ebp-0AECh],eax
0c2c4e6d ff35f0a07f05    push    dword ptr ds:[57FA0F0h] ("normal-main.bmp")
0c2c4e73 8bc8            mov     ecx,eax
0c2c4e75 33d2            xor     edx,edx
0c2c4e77 3909            cmp     dword ptr [ecx],ecx
0c2c4e79 e8f2374565      call    System_Windows_Forms_ni!System.Windows.Forms.ImageList.ImageCollection.SetKeyName (71718670)
>>> 0c2c4e7e 8b8e74020000    mov     ecx,dword ptr [esi+274h]
...

从卦象看，尼玛。。。执行第一个 SetKeyName(0, "normal-main.bmp"); 就异常啦，这就说明那个 Count=0，无语了，为什么 Count=0 呢？ 接下来寻找Count数据源ImageCollection 集合，可以从线程栈中寻找，使用 !dso 命令即可。

0:000> !dso
OS Thread Id: 0x534 (0)
ESP/REG  Object   Name
026FD774 4d6f0c74 System.Windows.Forms.ImageList+ImageCollection
026FD778 4d6f0ca0 System.IndexOutOfRangeException
...

0:000> !do 4d6f0c74
Name:        System.Windows.Forms.ImageList+ImageCollection
MethodTable: 71120ff0
EEClass:     70f230ec
Size:        20(0x14) bytes
File:        C:\Windows\Microsoft.Net\assembly\GAC_MSIL\System.Windows.Forms\v4.0_4.0.0.0__b77a5c561934e089\System.Windows.Forms.dll
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
7111ecc0  4003916        4 ...s.Forms.ImageList  0 instance 4d6d97b0 owner
72d909dc  4003917        8 ...ections.ArrayList  0 instance 4d6f0c88 imageInfoCollection
72d8df5c  4003918        c         System.Int32  1 instance       -1 lastAccessedIndex
0:000> !DumpObj /d 4d6d97b0
Name:        System.Windows.Forms.ImageList
...
Fields:
      MT    Field   Offset                 Type VT     Attr    Value Name
71121b0c  4001013       10 ...t+NativeImageList  0 instance 4d6f0c40 nativeImageList
728e15a0  4001019       1c ...Collections.IList  0 instance 00000000 originals

根据卦中的 nativeImageList 和 originals 再配合源代码，应该就是祸首 SafeNativeMethods.ImageList_GetImageCount 方法返回 0 导致的，先观察一下它的签名。

[DllImport("comctl32.dll")]
public static extern int ImageList_GetImageCount(HandleRef himl);

从签名看这是C++写的外部方法，这就沃草了。。。我总不能用 ida 去捋这里面的逻辑吧。。。到这里貌似已经快要撞到南墙了。。。有点慌了。

3. 天要绝人之路吗

经过短暂的恍恍惚惚之后，我突然灵光一现，尼玛这是32bit的内存地址，是不是2G的空间不够用哦？刚好 ImageList_GetImageCount 是一个关于图片的UI控件，用了底层的COM资源，会不会真的是空间不足导致的？有了这个想法之后赶紧 !address -summary 观察提交内存。

0:000> !address -summary
...
--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_COMMIT                             1933          6e768000 (   1.726 GB)  93.52%   86.30%
MEM_FREE                                631           9e01000 ( 158.004 MB)            7.72%
MEM_RESERVE                             607           7a87000 ( 122.527 MB)   6.48%    5.98%
...

尼玛。。。卦象中的 MEM_COMMIT=1.72G， %ofBusy= 93.52% 早已超过了1.2G的临界值，终于真相大白。。。

解决办法就比较简单了，开启大地址，让程序吃 4G 的内存，后来朋友反馈这个问题已不再出来。。。

三：总结

分析完这个dump之后其实我挺感慨的，人生也如此dump一样，在真相和假象之间不断的交织穿梭，有些人走出来了，有些人永远留在了里面。。。