经验首页 前端设计 程序设计 Java相关 移动开发 数据库/运维 软件/图像 大数据/云计算 其他经验
当前位置:技术经验 » 程序设计 » ASP.net » 查看文章
记一次 .NET某工控 宇宙射线 导致程序崩溃分析
来源:cnblogs  作者:一线码农  时间:2023/12/26 9:52:06  对本文有异议

一:背景

1. 讲故事

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


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

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

二:Windbg 分析

1. 为什么会崩溃

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

  1. 0:083> !analyze -v
  2. CONTEXT: (.ecxr)
  3. rax=0000024f82c77341 rbx=000000f275dfe7f0 rcx=00007ffb05e55658
  4. rdx=7ffb083d8c582d89 rsi=0000000000000000 rdi=000000f275dfe300
  5. rip=00007ffb64be082f rsp=000000f275dfeaa0 rbp=000000007ffb05ee
  6. r8=0000024ff9bc0810 r9=deb6f5c6f59b3377 r10=1441a86c71655650
  7. r11=ebbed78e94800000 r12=00007ffb05e55640 r13=0000000000000020
  8. r14=0000024b26a3d9e0 r15=0000024f82c77340
  9. iopl=0 ov up ei ng nz na po cy
  10. cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010a85
  11. clr!WKS::gc_heap::background_mark_simple1+0x516:
  12. 00007ffb`64be082f 4c8b02 mov r8,qword ptr [rdx] ds:7ffb083d`8c582d89=????????????????
  13. Resetting default scope
  14. EXCEPTION_RECORD: (.exr -1)
  15. ExceptionAddress: 00007ffb64be082f (clr!WKS::gc_heap::background_mark_simple1+0x0000000000000516)
  16. ExceptionCode: c0000005 (Access violation)
  17. ExceptionFlags: 00000001
  18. NumberParameters: 2
  19. Parameter[0]: 0000000000000000
  20. Parameter[1]: ffffffffffffffff
  21. Attempt to read from address ffffffffffffffff
  22. STACK_TEXT:
  23. 000000f2`75dfeaa0 00007ffb`64be03a0 : clr!WKS::gc_heap::background_mark_simple1+0x516
  24. 000000f2`75dfeb00 00007ffb`64be074e : clr!WKS::gc_heap::background_mark_simple+0x6d
  25. 000000f2`75dfeb30 00007ffb`64a45fc7 : clr!WKS::gc_heap::background_promote+0x98
  26. ...

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

  1. 0:083> !verifyheap
  2. object 0000024f82c76b18: bad member 0000024F82C77F40 at 0000024F82C76B70
  3. Last good object: 0000024F82C76AA0.
  4. object 0000024f82c76ca8: bad member 0000024F82C77340 at 0000024F82C76CB0
  5. Last good object: 0000024F82C76C58.
  6. object 0000024f82c76fa8: bad member 0000024F82C77050 at 0000024F82C76FD0
  7. Last good object: 0000024F82C76F88.
  8. Could not request method table data for object 0000024F82C77050 (MethodTable: 00007FFB3C032138).
  9. Last good object: 0000024F82C76FA8.

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

  1. 0:083> !do 0000024f82c76b18
  2. Name: System.Windows.Forms.TreeNode
  3. MethodTable: 00007ffb3c431af8
  4. EEClass: 00007ffb3c488500
  5. Size: 168(0xa8) bytes
  6. File: C:\xxxx\System.Windows.Forms.dll
  7. Fields:
  8. MT Field Offset Type VT Attr Value Name
  9. ...
  10. 00007ffb3c431ed8 400263f 58 ....Forms.TreeNode[] 0 instance 0000024f82c77f40 children
  11. ...
  12. 0:083> !do 0000024f82c77f40
  13. <Note: this object has an invalid CLASS field>
  14. Invalid object

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

  1. 0:083> dp 0000024f82c77f40 L4
  2. 0000024f`82c77f40 00007ffb`3c411ed8 00000000`00400008
  3. 0000024f`82c77f50 0000024f`82c56fa8 0000024f`82c57378
  4. 0:083> !dumpmt 00007ffb`3c411ed8
  5. 00007ffb3c411ed8 is not a MethodTable

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

接下来仔细观察 00007ffb3c411ed800007ffb3c431ed8 这两个地址,会发现一个是 3c41 一个是 3c43,真的是无语了,截图如下:

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

  1. 0:083> !do 0000024f82c76fa8
  2. Name: System.Windows.Forms.TreeNode
  3. MethodTable: 00007ffb3c431af8
  4. EEClass: 00007ffb3c488500
  5. Size: 168(0xa8) bytes
  6. Fields:
  7. MT Field Offset Type VT Attr Value Name
  8. ...
  9. 00007ffb3c432138 4002636 28 ...eNodeImageIndexer 0 instance 0000024f82c77050 imageIndexer
  10. ...
  11. 0:083> !do 00007ffb`3c032138
  12. <Note: this object has an invalid CLASS field>
  13. Invalid object
  14. 0:083> dp 0000024f82c77050 L1
  15. 0000024f`82c77050 00007ffb`3c032138

从卦中数据看:方法表 00007ffb3c03213800007ffb3c432138 也是差了一个bit位,即 3c033c43 的差别。

2. 为什么会翻转

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

  1. 0:083> !address 00007ffb3c432138
  2. Usage: Image
  3. Base Address: 00007ffb`3c431000
  4. End Address: 00007ffb`3c434000
  5. Region Size: 00000000`00003000 ( 12.000 kB)
  6. State: 00001000 MEM_COMMIT
  7. Protect: 00000004 PAGE_READWRITE
  8. Type: 01000000 MEM_IMAGE
  9. Allocation Base: 00007ffb`3c400000
  10. Allocation Protect: 00000080 PAGE_EXECUTE_WRITECOPY
  11. Image Path: C:\Windows\assembly\NativeImages_v4.0.30319_64\System.Windows.Forms\1534a59650e0fd08da0ed8931d9f6d5f\System.Windows.Forms.ni.dll
  12. Module Name: System_Windows_Forms_ni
  13. Loaded Image Name:
  14. Mapped Image Name:
  15. More info: lmv m System_Windows_Forms_ni
  16. More info: !lmi System_Windows_Forms_ni
  17. More info: ln 0x7ffb3c432138
  18. More info: !dh 0x7ffb3c400000
  19. Content source: 1 (target), length: 1ec8

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

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

三:总结

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

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

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

图片名称

原文链接:https://www.cnblogs.com/huangxincheng/p/17925800.html

 友情链接:直通硅谷  点职佳  北美留学生论坛

本站QQ群:前端 618073944 | Java 606181507 | Python 626812652 | C/C++ 612253063 | 微信 634508462 | 苹果 692586424 | C#/.net 182808419 | PHP 305140648 | 运维 608723728

W3xue 的所有内容仅供测试,对任何法律问题及风险不承担任何责任。通过使用本站内容随之而来的风险与本站无关。
关于我们  |  意见建议  |  捐助我们  |  报错有奖  |  广告合作、友情链接(目前9元/月)请联系QQ:27243702 沸活量
皖ICP备17017327号-2 皖公网安备34020702000426号