一:背景

1. 讲故事

上个月有个朋友在微信上找到我,说他们的软件在客户那边隔几天就要崩溃一次,一直都没有找到原因,让我帮忙看下怎么回事,确实工控类的软件环境复杂难搞,朋友手上有一个崩溃的dump,刚好丢给我来分析一下。

二:WinDbg分析

1. 程序为什么会崩溃

windbg 有一个厉害之处在于双击之后可以帮你自动定位到崩溃处,输出如下:


................................................................
................................................................
.......................................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(1418.89c): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
clr!WKS::gc_heap::background_mark_simple1+0x5a1:
000007fe`f5316d40 41f70300000080 test dword ptr [r11],80000000h ds:00000000`00000000=????????

从卦中信息看,这不是一件好事情,崩溃居然落在bgc线程上,此时bgc线程正在做后台对象标记,依据过往经验有可能是托管堆损坏了,可以用 !verifyheap 命令来验证下。


0:038> !verifyheap
Object 000000000476a0a8 has an invalid method table.
Last good object: 000000000476A058. 0:038> !lno 000000000476a0a8
Before: 000000000476a058 80 (0x50) System.Text.RegularExpressions.RegexWriter
After: 000000000476a0c0 152 (0x98) System.Int32[] 0:038> dp 000000000476a058
00000000`0476a058 000007fe`f0e47390 00000000`0476a0c0
00000000`0476a068 00000000`0476a1d0 00000000`0476a158
00000000`0476a078 00000000`0476a1a8 00000000`00000000
00000000`0476a088 0000001a`00000000 00000006`0000001a
00000000`0476a098 00000000`00000000 00000000`00000018
00000000`0476a0a8 00000000`00000000 00000000`00000000
00000000`0476a0b8 00000000`00000000 000007fe`f2ce9250
00000000`0476a0c8 00000000`00000020 00000004`00000000

从卦中看确实有一个对象处于有损状态,它的 mt=0 ,objheader=0x18,这个信息还是蛮奇怪的,接下来观察下内存地址的布局,找出有损地址空间,截图如下:

上面圈出来的地址段也不像是 C++ 故意改的,那到底是真破坏还是假破坏呢?因为这一点确实可以决定后续的分析方向。

2. 托管堆真假破坏之谜

熟悉 bgc 运转逻辑的朋友都知道会有三个阶段,分别为 初始标记,并发标记,最终标记,所以接下来的问题是当前这个程序处于什么阶段呢? 这个观察手段比较多,除了看bgc流程也可以 !t -special 看看 SuspendEE 标记。


0:038> !t -special
ThreadCount: 40
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
24 12 174c 000000001e71c210 1029220 Cooperative 0000000000000000:0000000000000000 000000000027ba40 2 MTA (GC) (Threadpool Worker)
...
38 13 89c 000000001e529130 21220 Preemptive 0000000000000000:0000000000000000 000000000027ba40 0 Ukn System.ExecutionEngineException 00000000022f1228 OSID Special thread type
24 174c SuspendEE ThreadpoolWorker

从卦中可以清晰的看到24号线程触发了一个前台GC,同时38号的 bgc抛了执行引擎异常,这个灾难性的异常也是程序崩溃的原因,接下来观察下 24号正在做什么。


0:024> k 10
# Child-SP RetAddr Call Site
00 00000000`205ebcf0 000007fe`f52fb444 clr!GcInfoDecoder::EnumerateLiveSlots+0x4df
01 00000000`205ec140 000007fe`f52fbd81 clr!EECodeManager::EnumGcRefs+0xc4
02 00000000`205ec2a0 000007fe`f5380aee clr!GcStackCrawlCallBack+0x171
03 00000000`205ec3a0 000007fe`f52fbc28 clr!Thread::StackWalkFrames+0x172
04 00000000`205ed820 000007fe`f53141f0 clr!CNameSpace::GcScanRoots+0x144
05 00000000`205ed8c0 000007fe`f5310a8e clr!WKS::gc_heap::relocate_phase+0x40
06 00000000`205ed930 000007fe`f5310fd0 clr!WKS::gc_heap::plan_phase+0xa01
07 00000000`205edb90 000007fe`f530df61 clr!WKS::gc_heap::gc1+0x9f
08 00000000`205edbe0 000007fe`f530dccd clr!WKS::gc_heap::garbage_collect+0x222
09 00000000`205edc70 000007fe`f530e220 clr!WKS::GCHeap::GarbageCollectGeneration+0xdd
0a 00000000`205edcc0 000007fe`f516ae69 clr!WKS::GCHeap::Alloc+0x29d
0b 00000000`205edd10 000007fe`f2b2ab2a clr!FramedAllocateString+0x139
...

从卦中可以清晰的看到此时的GC正在 relocate_phase 重定位阶段,重定位阶段通俗来说就是 兵马未动,粮草先行,这是一种非原子性的操作,简单来说bgc拿到的可能是移动后的新地址(粮草),但对象(兵马)还是在老地方,所以刚才看到的托管堆那块空间是初始化状态,同时对象头的 0x18 应该是一种中间状态的对象标记,这个暂时不去深挖了,但不管怎么说,此时的托管堆大概率是没有问题的。

既然托管堆没有问题,后面的研究方向就得深挖 bgc 的逻辑了。

3. bgc线程到底怎么了

要知道 bgc 到底怎么了,必须要观察它附近的汇编代码,可以用 ub 命令,输出如下:


0:024> r
Last set context:
rax=000000000001b83b rbx=0000000020e5e5b0 rcx=0000000000370707
rdx=00000000029b78a0 rsi=0000000000000000 rdi=0000000020e5e0c0
rip=000007fef5316d40 rsp=0000000020e5e680 rbp=000000001a30a2fc
r8=0000000003707670 r9=000007fef2c94438 r10=00000000029b88b0
r11=0000000000000000 r12=0000000000000010 r13=000007fef2c94438
r14=0000000000291808 r15=0000000000001f60
iopl=0 nv up ei pl zr na po nc
cs=0033 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010244
clr!WKS::gc_heap::background_mark_simple1+0x5a1:
000007fe`f5316d40 41f70300000080 test dword ptr [r11],80000000h ds:00000000`00000000=???????? 0:024> ub 000007fe`f5316d40
clr!WKS::gc_heap::background_mark_simple1+0x584:
000007fe`f5316d23 48c1e809 shr rax,9
000007fe`f5316d27 80e11f and cl,1Fh
000007fe`f5316d2a 41d3e3 shl r11d,cl
000007fe`f5316d2d 44855c8500 test dword ptr [rbp+rax*4],r11d
000007fe`f5316d32 7548 jne clr!WKS::gc_heap::background_mark_simple1+0x5f3 (000007fe`f5316d7c)
000007fe`f5316d34 44095c8500 or dword ptr [rbp+rax*4],r11d
000007fe`f5316d39 4d8b18 mov r11,qword ptr [r8]
000007fe`f5316d3c 4983e3fe and r11,0FFFFFFFFFFFFFFFEh

从卦中数据来看,崩溃的原因是 r11=0 导致的,r11 的值又来自于 r8,这里有一个硬编码值 0FFFFFFFFFFFFFFFEh,这个值在代码中应该是 -2 或者是 ~1 这两种情况,接下来观察下 background_mark_simple1() 的方法源码,尼玛。。。 还真给我找到了,简化后如下:


void gc_heap::background_mark_simple1(uint8_t * oo THREAD_NUMBER_DCL)
{
...
uint8_t* start = oo;
if ((size_t)oo & 1)
{
oo = (uint8_t*)((size_t)oo & ~1);
start = *(--background_mark_stack_tos);
dprintf(4, ("oo: %Ix, start: %Ix\n", (size_t)oo, (size_t)start));
}
...
}

先简单解释下代码的意思, oo & ~1 是将 oo 对象的 gcmark标记 给去掉,后面的 background_mark_stack_tos 就是深度优先遍历过程中使用的栈结构,再结合汇编代码,我们知道 r8 其实就是 oo,那这个 oo 到底是独立存在还是归属于谁呢?

4. oo 到底是何方神圣

要想知道这个答案,可以用 !lno 命令观察下 r8 附近内存来寻找蛛丝马迹,输出如下:


0:024> r r8
Last set context:
r8=0000000003707670 0:024> !lno 0000000003707670
Before: 0000000003707658 80 (0x50) xxx.ComponentData
After: 00000000037076a8 1416 (0x588) Free
Heap local consistency confirmed. 0:024> ? 0000000003707670 - 0000000003707658
Evaluate expression: 24 = 00000000`00000018 0:024> !DumpObj /d 0000000003707658
Name: xxx.ComponentData
MethodTable: 000007fe95c0b058
EEClass: 000007fe95c2bbb0
Size: 80(0x50) bytes
File: C:\xxxDriver.dll
Fields:
MT Field Offset Type VT Attr Value Name
000007fef2cecf58 400008c 38 System.DateTime 1 instance 0000000003707690 wWfscFiguq
000007fef2cffc90 400008d 18 System.Double 1 instance 0.000000 I9ss25rNyt
000007fe95c0a888 400008e 20 System.Int32 1 instance 9 AxCs5sGCxm
000007fe95c0af00 400008f 24 System.Int32 1 instance 9 fK9sgqZ2qY
...

这个卦看起来就非常奇怪,无语了。。。 我苦苦寻找的 oo 对象居然是一个 int 类型的 fK9sgqZ2qY 字段,这不是乱套了吗? int 类型在这里也没有装箱,怎么可能会提取出 mt 呢? 真的是莫名奇怪。

5. int 为什么当 引用类型 了

线索到了这里越来越不可思议了,基本就可以断定这是 BGC 标记的错乱,直白的说就是 BGC 出现了 bug,再看下当前的操作系统和framework的版本,依次是 windows7 和 4.0 。


0:024> vertarget
Windows 7 Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: SingleUserTS
Edition build lab: kernel32.dll version: 6.1.7601.17514 (win7sp1_rtm.101119-1850) 0:024> !eeversion
4.0.30319.18408 free
Workstation mode
In plan phase of garbage collection
SOS Version: 4.0.30319.18408 retail build

综合来说是 bgc 在老环境下做后台标记的时候出现了 bug,这种 bug 非我能力之所及,但我能做的就是把它切除掉,即把 bgc 模式给关掉,不走这个逻辑不就行了吗? 参考如下:


<configuration>
<runtime>
<gcConcurrent enabled="false"/>
</runtime>
</configuration>

三:总结

很多时候分析下来发现是CLR内部的bug所致,这种真的很无奈,我能做的也只能是手术切除。

记一次 .NET某炉膛锅炉检测系统 崩溃分析的更多相关文章

  1. 记一次 .NET 某企业 ERP网站系统 崩溃分析

    一:背景 1. 讲故事 前段时间收到了一个朋友的求助,说他的ERP网站系统会出现偶发性崩溃,找了好久也没找到是什么原因,让我帮忙看下,其实崩溃好说,用 procdump 自动抓一个就好,拿到 dump ...

  2. 记一次 .NET 某自动化集采软件 崩溃分析

    一:背景 1.讲故事 前段时间有位朋友找到我,说他的程序在客户的机器上跑着跑着会出现偶发卡死,然后就崩掉了,但在本地怎么也没复现,dump也抓到了,让我帮忙看下到底怎么回事,其实崩溃类的dump也有简 ...

  3. 记一次 .NET 某医疗住院系统 崩溃分析

    一:背景 1. 讲故事 最近收到了两起程序崩溃的dump,查了下都是经典的 double free 造成的,蛮有意思,这里就抽一篇出来分享一下经验供后面的学习者避坑吧. 二:WinDbg 分析 1. ...

  4. 记一次 .NET 某工控MES程序 崩溃分析

    一:背景 1.讲故事 前几天有位朋友找到我,说他的程序出现了偶发性崩溃,已经抓到了dump文件,Windows事件日志显示的崩溃点在 clr.dll 中,让我帮忙看下是怎么回事,那到底怎么回事呢? 上 ...

  5. 记一次 .NET某医疗器械清洗系统 卡死分析

    一:背景 1. 讲故事 前段时间协助训练营里的一位朋友分析了一个程序卡死的问题,回过头来看这个案例比较经典,这篇稍微整理一下供后来者少踩坑吧. 二:WinDbg 分析 1. 为什么会卡死 因为是窗体程 ...

  6. dlib人脸关键点检测的模型分析与压缩

    本文系原创,转载请注明出处~ 小喵的博客:https://www.miaoerduo.com 博客原文(排版更精美):https://www.miaoerduo.com/c/dlib人脸关键点检测的模 ...

  7. Snort 入侵检测系统

    Snort 入侵检测系统 一.实验目的 1.掌握snort IDS工作原理 2.应用snort 三种方式工作 二.实验环境 系统环境:Windows环境, kali环境 三.实验原理 1.snort ...

  8. 开源入侵检测系统OSSEC搭建之二:客户端安装

    上一篇文章中已经将OSSEC服务端的安装以及客户端的Key导出操作做了解说,接下来在另一台虚拟机中安装客户端,与安装服务端类似同样需要安装ossec,步骤如下. 一.下载ossec-hids-2.8. ...

  9. 开源入侵检测系统OSSEC搭建之一:服务端安装

    OSSEC是一款开源的多平台的入侵检测系统,可以运行于Windows, Linux, OpenBSD/FreeBSD, 以及 MacOS等操作系统中.主要功能有日志分析.完整性检查.rootkit检测 ...

  10. 基于DSP的疲劳驾驶检测系统的研究

    原地址:http://www.chinaaet.com/article/index.aspx?id=114534 关键词:疲劳检测DSP亮瞳效应PERCLOS 摘  要: 针对汽车驾驶员疲劳驾驶检测的 ...

随机推荐

  1. Codeforces Round 914 (Div. 2)A~C

    A 反过来考虑,由皇后和国王的位置去寻找骑士的位置,当一个点既可以被皇后找到,也可以被国王找到时就说明这个点是满足条件的 #include <bits/stdc++.h> #define ...

  2. select 条件语句【GO 基础】

    〇.select 简介 select 语句类似于 switch 语句,但是 select 会随机执行一个可运行的 case.如果没有 case 可运行,它将阻塞,直到有 case 可运行. selec ...

  3. wav 格式音频文件生成例子

    wavfile is a simple sound library for use in CSE 20211. This library allows you to generate arbitrar ...

  4. 从一线方案商的角度来看高通QCC3020芯片

    写在前面的话   QCC3020的推出已经有一段时间了.在蓝牙音频的圈子里,属于家喻户晓的芯片了.再加上高通的大力宣传和一些顶尖级产品的使用,可以说,它是高通在吸收CSR的技术之后,着力推出的最具竞争 ...

  5. c语言中的指针,数组和结构体结合的一个经典案例

    一 你真正懂了C语言了吗? 很多人刚把c语言用了两年,就以为很懂,等遇到稍微深层次一点的问题,就卡住了.这里,有一个问题,可以考察你对这三者理解如何. 二 一个例子: #include <std ...

  6. Kotlin学习快速入门(10)—— 重载运算符使用

    原文:Kotlin学习快速入门(10)-- 重载运算符使用 - Stars-One的杂货小窝 Kotlin中提供了基础的运算符,但是只是针对基础的数据类型,如Int,Double等 如果我们想让两个对 ...

  7. Android自定义View学习(1)——基础知识介绍

    原文:Android自定义View学习(1)--基础知识介绍 - Stars-One的杂货小窝 准备学习自定义View,介绍一下先了解了下相关的前置基础知识,特此总结 本系列集合文章链接可访问Andr ...

  8. ypipe, zmq的核心部件,无锁读写的管道。

    必须指出,无锁读写只限于单个读跟单个写之间,读与读,还有写与写之间必须确保同步.所以ypipe不必读写锁rwlock或者读写之间的锁,但需要读锁跟写锁两个锁,在读端之间或在写端之间仍然是临界资源.本质 ...

  9. 算法研究之快速排序java版

    很早之前就已经接触过快速排序算法了,面试当中也屡屡被问到,虽然明白其原理,但从未真正的用代码敲出来. 写关于算法的代码之前一定要原理想明白,不然就是盲目,在参考有关资料及自己的沉思之后,写出如下代码, ...

  10. 【AtCoder Beginner Contest 330)】[E - Mex and Update ] 线段树+二分

    本题可以用线段树+二分的方式实现.代码如下: import java.io.IOException; import java.io.InputStreamReader; import java.io. ...