记一次 .NET某实验室自动进样系统 崩溃分析

一：背景

1. 讲故事

前些天有位朋友在微信上联系到我，说他们的程序在客户那边崩掉了，让我帮忙看下怎么回事，dump也拿到了，那就上手分析吧。

二：WinDbg 分析

1. 哪里的崩溃

既然是程序的崩溃，自然是有原因的，皮裤套棉裤，必定有缘故，不是皮裤太薄就是棉裤没毛，用!analyze -v观察下异常信息。

0:107> !analyze -vCONTEXT: (.ecxr)rax=0000005e0dc7c4a0 rbx=0000005e0dc7c400 rcx=0000005e0dc7c4a0rdx=0000000000000000 rsi=0000005e0dc7c3f0 rdi=0000005e0dc7c4a0rip=00007ffb1ecfc223 rsp=0000005e0dc7c3c0 rbp=0000005e0dc7c4c0 r8=00000000000004d0 r9=0000000000000000 r10=0000000000000000r11=0000005e0dc7c4a0 r12=0000000000000000 r13=000002079d450220r14=000002079b93aba0 r15=0000000000000000iopl=0 nv up ei pl nz na pe nccs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00000200coreclr!EEPolicy::HandleFatalError+0x7f:00007ffb`1ecfc223 488d442440 lea rax,[rsp+40h]Resetting default scopeEXCEPTION_RECORD: (.exr -1)ExceptionAddress: 00007ffb1ec6d70f (coreclr!ProcessCLRException+0x00000000000d9f7f) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000001NumberParameters: 0

从卦中信息看这是一个经典的访问违例，但崩溃在EEPolicy::HandleFatalError 处就有点匪夷所思了，HandleFatalError 方法主要是用来在抛异常之前修整异常上下文的，这个方法固若金汤，一般不会出问题的，但不管怎么样，还是看下 rsp+40h到底是什么东西。

0:107> dp rsp+40h L10000005e`0dc7c400 00000001`c0000005

上面的c0000005很显然是访问违例，看样子这里有点混乱，也不是第一崩溃现场，这里就不过多纠结了，那怎么去找真正的崩溃点呢？还有一个方法就是去找RaiseException或者KiUserExceptionDispatch返回点之前的有用函数，参考如下：

0:107> .ecxr0:107> k *** Stack trace for last set context - .thread/.cxr resets it # Child-SP RetAddr Call Site00 0000005e`0dc7c3c0 00007ffb`1ec6d72e coreclr!EEPolicy::HandleFatalError+0x7f [D:\a\_work\1\s\src\coreclr\vm\eepolicy.cpp @ 776] 01 0000005e`0dc7c9d0 00007ffb`5235292f coreclr!ProcessCLRException+0xd9f9e [D:\a\_work\1\s\src\coreclr\vm\exceptionhandling.cpp @ 1036] 02 0000005e`0dc7cc00 00007ffb`52302554 ntdll!RtlpExecuteHandlerForException+0xf03 0000005e`0dc7cc30 00007ffb`5235143e ntdll!RtlDispatchException+0x24404 0000005e`0dc7d340 00000000`6c942893 ntdll!KiUserExceptionDispatch+0x2e05 0000005e`0dc7daf0 00007ffa`c066ed7b libxxx_manage!get_clean_xxx06 0000005e`0dc7db70 00007ffa`c06b73a4 0x00007ffa`c066ed7b...

从卦中看，程序崩溃在libxxx_manage!get_clean_xxx 中，看样子是一个 C++ 写的动态链接库，这就有点无语了。。。

2. C++ 库为什么会崩

要想寻找答案，最好的办法就是观察000000006c942893处的汇编代码，参考如下：

0:107> ub 00000000`6c942893libxxx_manage!get_clean_xxx:00000000`6c942876 55 push rbp00000000`6c942877 53 push rbx00000000`6c942878 4883ec68 sub rsp,68h00000000`6c94287c 488dac2480000000 lea rbp,[rsp+80h]00000000`6c942884 48894d00 mov qword ptr [rbp],rcx00000000`6c942888 c745dc00000000 mov dword ptr [rbp-24h],000000000`6c94288f 488b4500 mov rax,qword ptr [rbp]0:107> u 00000000`6c94289300000000`6c942893 488b00 mov rax,qword ptr [rax]0:107> dp rbp L10000005e`0dc7c4c0 00000000`00000000

从上面的汇编代码来看，这是 get_clean_xxx 方法的序幕代码，问题出在 rbp 的内容为0上，但 rbp 又来自于 rcx，根据 x64调用协定，rcx 即方法的第一个参数，看样子是这个参数为 null 导致的，参考如下：

0:107> !address rcxUsage: StackBase Address: 0000005e`0dc78000End Address: 0000005e`0dc80000Region Size: 00000000`00008000 ( 32.000 kB)State: 00001000 MEM_COMMITProtect: 00000004 PAGE_READWRITEType: 00020000 MEM_PRIVATEAllocation Base: 0000005e`0db00000Allocation Protect: 00000004 PAGE_READWRITEMore info: ~107k0:107> dp rcx L10000005e`0dc7c4a0 00000000`00000000

3. get_clean_xxx 参数为null吗

这个问题比较简单，继续用!clrstack 观察下 Pinvoke 之上的 C# 代码。

0:107> !clrstackOS Thread Id: 0x3508 (107) Child SP IP Call Site0000005E0DC7DBA0 00007ffac066ed7b [InlinedCallFrame: 0000005e0dc7dba0] xxx_LibPInvoke.xxx_clean_query(IntPtr)0000005E0DC7DB70 00007ffac066ed7b ILStubClass.IL_STUB_PInvoke(IntPtr)0000005E0DC7DC30 00007ffac06b73a4 xx+c__DisplayClass11_0.<xxxQueryClean>b__0(IntPtr)...

接下来就是看下托管层的 C# 代码是如何写的，截图如下：

从图中可以清楚的看到，xxxChannel 传给C++ 的时候没有判断是否为null，导致崩溃的发生，那还有没有其他的佐证呢？其实也是有的，如果符号给力还可以使用 !clrstack -a去找到xxxChannel传下去的值。

0:107> !clrstack -aOS Thread Id: 0x3508 (107) Child SP IP Call Site0000005E0DC7DBA0 00007ffac066ed7b [InlinedCallFrame: 0000005e0dc7dba0] xxx_LibPInvoke.xxx_clean_query(IntPtr)0000005E0DC7DB70 00007ffac066ed7b ILStubClass.IL_STUB_PInvoke(IntPtr) PARAMETERS: <no data>0000005E0DC7DC30 00007ffac06b73a4 xxx+c__DisplayClass11_0.<xxxQueryClean>b__0(IntPtr) PARAMETERS: this (0x0000005E0DC7DC80) = 0x0000020a9d9ca8d8 xxxChannel (0x0000005E0DC7DC88) = 0x0000000000000000 LOCALS: 0x0000005E0DC7DC6C = 0x0000000000000000 0x0000005E0DC7DC68 = 0x0000000000000000

可以清楚的看到确实是 0，到这里就一切真相大白，对参数加一个判断即可，那这东西到底是谁的责任呢？我觉得双方都有问题吧。

1. 写托管层的人有点飘。
2. 写非托管层的人未作防御性编程，还是年轻太相信人了。

三：总结

这次生产事故彻底破坏了两个语言团队之间的相互合作的信任度，信任重建可就难了，不怕神一样的对手，就怕猪猪一样的队友，放在这里还是挺合适的，哈哈，开个小玩笑。