记一次 .NET某工厂报警监控设置 崩溃分析

古德摸零

一：背景

1. 讲故事

前些天有位朋友在微信上丢了一个崩溃的dump给我，让我帮忙看下为什么出现了崩溃，在 Windows 的事件查看器上显示的是经典的 访问违例 ，即 c0000005 错误码，不管怎么说有dump就可以上windbg开干了。
二：WinDbg 分析

1. 程序为谁崩溃了

在 Windows 平台上比较简单，可以用 !analyze -v 命令查看，输出结果如下：

1. 0:120> !analyze -v
2. ...
3. CONTEXT:  (.ecxr)
4. rax=0000000000000000 rbx=000000d5140fcf00 rcx=0000000000000000
5. rdx=000001d7f61cf1d8 rsi=000001d7d3635a10 rdi=000000d5140fc890
6. rip=00007ff80e17d233 rsp=000000d5140fc760 rbp=000000d5140fc8a0
7. r8=000001d7d3308144  r9=0000000000000000 r10=0000000000000000
8. r11=000001d96736b620 r12=000000d5140fca08 r13=00007ff80d326528
9. r14=000000d5140fcf00 r15=0000000000000000
10. iopl=0         nv up ei pl nz na po nc
11. cs=0033  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00010206
12. 00007ff8`0e17d233 3909            cmp     dword ptr [rcx],ecx ds:00000000`00000000=????????
13. Resetting default scope
15. EXCEPTION_RECORD:  (.exr -1)
16. ExceptionAddress: 00007ff80e17d233
17.    ExceptionCode: c0000005 (Access violation)
18.   ExceptionFlags: 00000000
19. NumberParameters: 2
20.    Parameter[0]: 0000000000000000
21.    Parameter[1]: 0000000000000000
22. Attempt to read from address 0000000000000000
24. ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p            0x%p                    %s
26. EXCEPTION_CODE_STR:  c0000005
28. STACK_TEXT:  
29. 000000d5`140fc760 00007ff8`6bcc6d93     : 000001d7`d3635a10 000000d5`140fcb80 00007ff8`6bcfda57 00007ff8`695acc92 : 0x00007ff8`0e17d233
30. 000000d5`140fc8b0 00007ff8`6bcc6c48     : 00000000`00000004 00007ff8`6be5ba73 00000000`00000000 00000000`00000000 : clr!CallDescrWorkerInternal+0x83
31. 000000d5`140fc8f0 00007ff8`6be5bf66     : 000001d7`d3635a10 00000000`00000000 000000d5`140fcad8 00000000`00000000 : clr!CallDescrWorkerWithHandler+0x4e
32. 000000d5`140fc930 00007ff8`6be5c41f     : 00000000`00000000 000000d5`140fca30 00000000`00000000 000000d5`140fcb60 : clr!CallDescrWorkerReflectionWrapper+0x1a
33. 000000d5`140fc980 00007ff8`69993ee4     : 00000000`00000000 00000000`00000000 000001d7`d3635a10 00007ff8`699f9700 : clr!RuntimeMethodHandle::InvokeMethod+0x45f
34. 000000d5`140fcf90 00007ff8`6997eeae     : 000001d7`d3376af0 00000000`00000000 00000000`0000011e 00007ff8`699f82f3 : mscorlib_ni!System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal+0x104
35. 000000d5`140fd000 00007ff8`699c3a06     : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : mscorlib_ni!System.Reflection.RuntimeMethodInfo.Invoke+0x8e
36. 000000d5`140fd080 00007ff8`0dfb7bb3     : 000001d7`d3635998 000001d7`d45e28e0 00000000`0000011c 000001d7`d3376af0 : mscorlib_ni!System.RuntimeType.InvokeMember+0x306
37. ...
38. STACK_COMMAND:  ~120s; .ecxr ; kb
39. ...

复制代码

从卦中信息看崩溃的汇编语句是 dword ptr [rcx],ecx ，经常看C#汇编代码的朋友我相信对这条语句非常敏感，对，它就是JIT自动插入的一条 this!=null 的防御性判断，看样子程序有 this=null 的情况，接下来入手点就是RIP处 ExceptionAddress: 00007ff80e17d233，用 !U 观察下上下文。

1. 0:120> !U 00007ff80e17d233
2. Normal JIT generated code
3. MyScript.Process()
4. Begin 00007ff80e17d1c0, size 3d5
5. 00007ff8`0e17d1c0 55              push    rbp
6. 00007ff8`0e17d1c1 57              push    rdi
7. 00007ff8`0e17d1c2 56              push    rsi
8. 00007ff8`0e17d1c3 4881ec30010000  sub     rsp,130h
9. 00007ff8`0e17d1ca c5f877          vzeroupper
10. ...
11. 00007ff8`0e17d220 e813c1edfe      call    00007ff8`0d059338 (xxx.GetRegion(System.String, Boolean), mdToken: 000000000600034f)
12. 00007ff8`0e17d225 48898570ffffff  mov     qword ptr [rbp-90h],rax
13. 00007ff8`0e17d22c 488b8d70ffffff  mov     rcx,qword ptr [rbp-90h]
14. >>> 00007ff8`0e17d233 3909            cmp     dword ptr [rcx],ecx
15. 00007ff8`0e17d235 e8de87edfe      call    00007ff8`0d055a18 (xxx.get_Region(), mdToken: 0000000006000073)

复制代码

从卦中的汇编代码看逻辑非常清晰，即 xxx.GetRegion() 方法返回为null，然后在取其中的 Region 属性时直接崩掉，说白了这是一个简单的 空引用异常，完整的代码截图如下：

奇怪就奇怪在这里，代码中明明用 try catch 给包起来了，为什么程序直接崩掉了。
2. 为什么try catch 无效

尼玛，这是我这几年做dump分析第一次遇到这种情况，真的是无语了，接下来我们验证下这个异常是否到了托管层？

• 是否有 NullReferenceException
  

熟悉dump分析的朋友应该知道，如果线程抛了异常在回溯的过程中会记录到 Thread.m_LastThrownObjectHandle 字段中，同时 !t 命令可以在 Exception 列中看到此信息。

1. 0:120> !t
2. ThreadCount:      48
3. UnstartedThread:  0
4. BackgroundThread: 47
5. PendingThread:    0
6. DeadThread:       0
7. Hosted Runtime:   no
8.                                                                                                         Lock  
9.        ID OSID ThreadOBJ           State GC Mode     GC Alloc Context                  Domain           Count Apt Exception
10.    0    1 29dc 000001d7d162d5d0    26020 Preemptive  000001D7D8228A00:000001D7D8228D28 000001d7d1602380 0     STA
11. ...
12. 159   18 22dc 000001d967906ff0  1029220 Preemptive  000001D7D834E558:000001D7D834E558 000001d7d1602380 1     MTA (GC) (Threadpool Worker)
13. ...

复制代码

但从卦中数据看所有的 Exception 列都没有异常信息，这就表示程序没有走到 CLR 的异常处理链条上，至少是不完整的。

• 是否有 AccessViolationException
  

参加过 C#内功修炼训练营 的朋友应该都知道，这种 c0000005 的异常在 C#层面最终会被map成两种异常中的其一，即 NullReferenceException 和 AccessViolationException，选择其一的逻辑就是判断 RIP 是在托管层还是非托管层，模型图如下：

但遗憾的是在 !t 的列表中也没有任何的 AccessViolationException 字样，这也更加确认了它没有调用异常处理链中的 CreateThrowable 函数。。。
事出反常必有妖，在 !t 的输出结果中可以看到此时 159号线程触发了 GC，接下来切过去看一看。

1. 0:120> ~159s
2. ntdll!NtQueryInformationThread+0x14:
3. 00007ff8`8317ea34 c3              ret
4. 0:159> k
5. # Child-SP          RetAddr               Call Site
6. 00 000000d5`00c3e7d8 00007ff8`7f216e2e     ntdll!NtQueryInformationThread+0x14
7. 01 000000d5`00c3e7e0 00007ff8`6bcea731     KERNELBASE!GetThreadPriority+0x1e
8. 02 000000d5`00c3e850 00007ff8`6be69cc5     clr!Thread::GetThreadPriority+0x56
9. 03 000000d5`00c3e8a0 00007ff8`6be69bc4     clr!ThreadSuspend::SuspendRuntime+0xa5
10. 04 000000d5`00c3e990 00007ff8`6bd814e3     clr!ThreadSuspend::SuspendEE+0x128
11. 05 000000d5`00c3ea90 00007ff8`6bd85f51     clr!WKS::GCHeap::GarbageCollectGeneration+0xb7
12. 06 000000d5`00c3eaf0 00007ff8`6be7ee6b     clr!WKS::gc_heap::trigger_gc_for_alloc+0x2d
13. 07 000000d5`00c3eb30 00007ff8`470e53ec     clr!JIT_New+0x4d6
14. 08 000000d5`00c3eee0 00007ff8`470e537c     Microsoft_VisualBasic_ni!Microsoft.VisualBasic.Strings.ReplaceInternal+0x3c [f:\dd\vb\runtime\msvbalib\Strings.vb @ 761]
15. 09 000000d5`00c3ef80 00007ff8`0d04f81f     Microsoft_VisualBasic_ni!Microsoft.VisualBasic.Strings.Replace+0x15c [f:\dd\vb\runtime\msvbalib\Strings.vb @ 737]
16. ...

复制代码

从卦中的线程栈来看，此时正在 SuspendEE 阶段，而且还是处于早期阶段，正在准备给 SuspendThread 安排一个好的优先级，主要是怕优先级太低了，导致 线程饥饿 得不到调度，毕竟 GC Process 的过程一定要是快中再快，接下来我们看下程序的 framework 版本。

1. 0:159> !eeversion
2. 4.7.3190.0 free
3. Workstation mode
4. SOS Version: 4.7.3190.0 retail build

复制代码

可以看到还是比较老的 .netframework 4.7.3，结合这么多信息，我个人觉得这可能是 CLR 的一个 bug，在 SuspendEE 阶段的早期（还没有 foreach threads）刚好遇到了一个硬件异常，这个 硬件异常 CLR 在业务逻辑上没处理好，导致 SEH 异常没有引入到 托管层，或者中途的某一环断掉了，我放一张C#内功修炼训练营 中的硬件异常完整流程图。

最后给到朋友的建议比较简单：

• 判 null 的时候一定要加 null 判断，避免异常逻辑。
  
• 升级 framework 到最新的 4.8.1 观察。
  

三：总结

这次程序崩溃的原因很简单，就是 空引用异常 ，但诡异就诡异在明明有 trycatch 在外部，硬是没接住，这个大概率是 CLR 的 bug，让我这个分析多年dump的老手都叹为观止，开了眼界，无语了无语了。。。

来源:https://www.cnblogs.com/huangxincheng/p/18246160
免责声明：由于采集信息均来自互联网，如果侵犯了您的权益，请联系我们【E-Mail:cb@itdo.tech】 我们会及时删除侵权内容，谢谢合作！