记一次 .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一样，在真相和假象之间不断的交织穿梭，有些人走出来了，有些人永远留在了里面。。。
