一:背景

1. 讲故事

前些天有一位朋友在公众号上找到我,说他们的WinForm程序部署在20多台机器上,只有两台机器上的程序会出现崩溃的情况,自己找了好久也没分析出来,让我帮忙看下怎么回事,就喜欢这些有点调试基础的,dump也不需要我指导怎么去抓,接下来我们就上windbg开始分析吧。

二:WinDbg分析

1. 为什么会崩溃

寻找崩溃的表象比较简单,使用 windbg 的 !analyze -v 命令即可。


0:000> !analyze -v
...
EXCEPTION_RECORD: (.exr -1)
ExceptionAddress: 0000000000000000
ExceptionCode: 80000003 (Break instruction exception)
ExceptionFlags: 00000000
NumberParameters: 0
...
STACK_TEXT:
0000003f`76f7ed58 00007ffa`f7c66d88 : 0000003f`00006120 00007ffa`f7bf98da 00000000`00000000 0000e4f5`bb3ba231 : user32!NtUserWaitMessage+0xa
0000003f`76f7ed60 00007ffa`f7bf9517 : 0000003f`00006120 0000003f`76f7ee80 00000000`00000000 00000000`00000000 : System_Windows_Forms_ni+0x2b6d88
0000003f`76f7ee10 00007ffa`f7bf8c2c : 0000003f`0006ec30 0000003f`00000001 0000003f`000c88c0 00000000`00000000 : System_Windows_Forms_ni+0x249517
0000003f`76f7ef10 00007ffa`f7bf8a25 : 0000003f`00006120 00000000`ffffffff 0000003f`00054848 0000003f`76f7f300 : System_Windows_Forms_ni+0x248c2c
0000003f`76f7efa0 00007ffa`9b4a0a08 : 0000003f`00007970 00000000`ffffffff 0000003f`000c88c0 0000003f`770bda90 : System_Windows_Forms_ni+0x248a25
0000003f`76f7f000 00007ffa`fab13753 : 00000000`00000001 0000003f`76f7f530 00007ffa`fac6710d 00000000`00000001 : 0x00007ffa`9b4a0a08
0000003f`76f7f040 00007ffa`fab1361c : 0000003f`00003330 00007ffa`f9acd94c 00000000`20000001 0000003f`00000000 : clr!CallDescrWorkerInternal+0x83
0000003f`76f7f080 00007ffa`fab144d3 : 00000000`00000000 00000000`00000004 0000003f`76f7f300 0000003f`76f7f3b8 : clr!CallDescrWorkerWithHandler+0x4e
0000003f`76f7f0c0 00007ffa`fac6f75a : 0000003f`76f7f200 00000000`00000000 00000000`00000000 00000000`00000000 : clr!MethodDescCallSite::CallTargetWorker+0x2af
0000003f`76f7f250 00007ffa`fac6f596 : 00000000`00000000 00000000`00000001 0000003f`00000000 00000000`00000000 : clr!RunMain+0x1ba
0000003f`76f7f430 00007ffa`fac6f4d4 : 0000003f`770bda90 0000003f`000015b0 0000003f`770bda90 0000003f`77093490 : clr!Assembly::ExecuteMainMethod+0xba
0000003f`76f7f720 00007ffa`fac6ea02 : 0000003f`76f7fd88 0000003f`76de0000 00000000`00000000 00000000`00000000 : clr!SystemDomain::ExecuteMainMethod+0x6b9
0000003f`76f7fd60 00007ffa`fac6e9b2 : 0000003f`76de0000 0000003f`76f7fee0 00000000`00000000 00007ffb`03c420e8 : clr!ExecuteEXE+0x43
0000003f`76f7fdd0 00007ffa`fac6e8f4 : ffffffff`ffffffff 00000000`00000000 00000000`00000000 00000000`00000000 : clr!_CorExeMainInternal+0xb2
0000003f`76f7fe60 00007ffb`03be6cf5 : 00000000`00000000 00000000`00000091 00000000`00000000 0000003f`76f7fe48 : clr!CorExeMain+0x14
0000003f`76f7fea0 00007ffb`03c8ea5b : 00000000`00000000 00007ffa`fac6e8e0 00000000`00000000 00000000`00000000 : mscoreei!CorExeMain+0xe0
0000003f`76f7fef0 00007ffb`0dc716ad : 00007ffb`03be0000 00000000`00000000 00000000`00000000 00000000`00000000 : mscoree!_CorExeMain_Exported+0xcb
0000003f`76f7ff20 00007ffb`0f924629 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : kernel32!BaseThreadInitThunk+0xd
0000003f`76f7ff50 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x1d STACK_COMMAND: ~0s; .ecxr ; kb
...

从卦中看,真的吸了一口凉气,尼玛这dump没记录到 crash 信息,有些朋友说这个 int 3 不是吗?简单的说不是,它是一个软trap,抓dump的时候会有一个进程的冻结,这个冻结就是 int 3,所以你看dump中有这个异常 99% 都是正常的。

2. 异常哪里去了

按往常的套路,我都会推荐procdump这款工具让朋友再抓一下,在重抓之前先看看可还有其他线索,可以用 !t 看看托管线程上是否挂了异常。


0:000> !t
ThreadCount: 76
UnstartedThread: 0
BackgroundThread: 69
PendingThread: 0
DeadThread: 6
Hosted Runtime: no
Lock
ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 26c4 0000003f770bda90 26020 Preemptive 0000000000000000:0000000000000000 0000003f77093490 0 STA
...
74 77 c544 0000003f1a08c470 21220 Preemptive 0000000000000000:0000000000000000 0000003f77093490 0 Ukn System.ExecutionEngineException 0000003f000011f8
75 78 18a88 0000003f1a329ae0 8029220 Preemptive 0000000000000000:0000000000000000 0000003f77093490 0 MTA (Threadpool Completion Port)

从卦中可以看到有一个线程抛了 System.ExecutionEngineException 异常,这是一个灾难性的情况,表示 CLR 在执行自身代码的时候崩掉了,惊讶之余赶紧看看它的线程栈为什么会崩。


0:074> k
# Child-SP RetAddr Call Site
00 0000003f`1bafea90 00007ffa`fb0283aa clr!WKS::gc_heap::background_mark_simple+0x36
01 0000003f`1bafeac0 00007ffa`fb028701 clr!WKS::gc_heap::revisit_written_page+0x2fe
02 0000003f`1bafeb50 00007ffa`fb01ffec clr!WKS::gc_heap::revisit_written_pages+0x251
03 0000003f`1bafec10 00007ffa`facefd01 clr!WKS::gc_heap::background_mark_phase+0x298
04 0000003f`1bafeca0 00007ffa`fb021fe5 clr!WKS::gc_heap::gc1+0xc0
05 0000003f`1bafed10 00007ffa`fab33e1e clr!WKS::gc_heap::bgc_thread_function+0x169
06 0000003f`1bafed50 00007ffb`0dc716ad clr!Thread::intermediateThreadProc+0x7d
07 0000003f`1baff810 00007ffb`0f924629 kernel32!BaseThreadInitThunk+0xd
08 0000003f`1baff840 00000000`00000000 ntdll!RtlUserThreadStart+0x1d 0:074> r
rax=000000001f808000 rbx=0000003f1bafe870 rcx=0000003efac80140
rdx=0000003f01000000 rsi=0000000000000000 rdi=0000003f1bafe380
rip=00007ffafb020c06 rsp=0000003f1bafea90 rbp=0000003f01c63270
r8=0000000000000000 r9=0000003f01c64000 r10=0000003f04271000
r11=0000000000000001 r12=00007ffa9bca83c0 r13=0000003f01c632a8
r14=ffffffffffffffff r15=0000003f01c63000
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_simple+0x36:
00007ffa`fb020c06 41f70000000080 test dword ptr [r8],80000000h ds:00000000`00000000=????????

从卦中信息看,当前是一个 bgc 线程,在后台标记对象的时候踩到了0区导致的崩溃,经验告诉我,是不是此时的托管堆损坏了? 可以用 !verifyheap 验证下。


0:000> !verifyheap
No heap corruption detected.

从卦中信息看,当前托管堆并没有损坏,作为一个经常为sos输出坑过的人,现在我是不相信这个输出的,所以我要找一下这个 r8 对象到底是什么对象,接下来反汇编下 background_mark_simple 方法。


0:074> ub 00007ffa`fb020c06
clr!WKS::gc_heap::background_mark_simple+0x1a:
00007ffa`fb020bea 0941d3 or dword ptr [rcx-2Dh],eax
00007ffa`fb020bed e048 loopne clr!WKS::gc_heap::background_mark_simple+0x67 (00007ffa`fb020c37)
00007ffa`fb020bef 8b0dd3253c00 mov ecx,dword ptr [clr!WKS::gc_heap::mark_array (00007ffa`fb3e31c8)]
00007ffa`fb020bf5 44850481 test dword ptr [rcx+rax*4],r8d
00007ffa`fb020bf9 7548 jne clr!WKS::gc_heap::background_mark_simple+0x73 (00007ffa`fb020c43)
00007ffa`fb020bfb 44090481 or dword ptr [rcx+rax*4],r8d
00007ffa`fb020bff 4c8b02 mov r8,qword ptr [rdx]
00007ffa`fb020c02 4983e0fe and r8,0FFFFFFFFFFFFFFFEh 0:074> r rdx
rdx=0000003f01000000 0:074> !lno rdx
Before: 0000003f00ffff38 512 (0x200) xxx.xxx
After: 0000003f01000138 32 (0x20) System.String
Heap local consistency confirmed. 0:074> ? 0000003f01000000 - 0000003f00ffff38
Evaluate expression: 200 = 00000000`000000c8 0:074> !do 0000003f00ffff38
Name: xxx.xxx
MethodTable: 00007ffa9c0ac278
EEClass: 00007ffa9c095b20
Size: 512(0x200) bytes
Fields:
MT Field Offset Type VT Attr Value Name
...
00007ffaf9d1da88 40012e6 c8 System.String 0 instance 0000000000000000 <OPPORTUNITY>k__BackingField
...

经过我上面的一顿分析,原来bgc标记的对象是 <OPPORTUNITY>k__BackingField 字段,同时也验证了确实托管堆没有损坏,接下来的问题是为什么BGC在mark这个字段的时候抛出来了异常呢?

3. 继续寻找真相

找不到突破口那就只能从线程栈上去挖,熟悉 bgc 后台标记的朋友应该知道,后台标记会分成三个阶段。

  • 初始标记阶段
  • 并发标记阶段
  • 最终标记阶段

截一张我在 .NET高级调试训练营 PPT里的图。

接下来的问题是这个程序目前处于哪一个阶段呢?根据线程栈上的 revisit_written_pages 方法,很显然是处于第二阶段,在第二阶段中为了能够识别对象修改的情况,CLR 使用了 Win32 的GetWriteWatch函数对内存页进行监控,监控到的脏内存页会在第三阶段做最后的清洗。

说了这么多,有没有源码支撑呢?这里我们简单看一下 coreclr 的源代码即可。


void gc_heap::revisit_written_pages(BOOL concurrent_p, BOOL reset_only_p)
{
get_write_watch_for_gc_heap(reset_watch_state, base_address, region_size,
(void**)background_written_addresses,
&bcount, is_runtime_suspended);
} // static
void gc_heap::get_write_watch_for_gc_heap(bool reset, void * base_address, size_t region_size,
void * *dirty_pages, uintptr_t * dirty_page_count_ref,
bool is_runtime_suspended)
{ bool success = GCToOSInterface::GetWriteWatch(reset, base_address, region_size, dirty_pages,
dirty_page_count_ref);
} bool GCToOSInterface::GetWriteWatch(bool resetState, void * address, size_t size, void * *pageAddresses, uintptr_t * pageAddressesCount)
{
uint32_t flags = resetState ? 1 : 0;
ULONG granularity; bool success = ::GetWriteWatch(flags, address, size, pageAddresses, (ULONG_PTR*)pageAddressesCount, &granularity) == 0;
if (success)
{
assert(granularity == OS_PAGE_SIZE);
} return success;
}

给了这么多的代码,主要是想说 bgc的并发标记利用了 Windows 提供的功能,结合朋友说的只有两台机器会出现这种情况,到这里大概可以给出两种方案:

  1. 更新Windows补丁,升级framework,大概率是两者的兼容性问题,导致内存页监控上出了问题。

  2. 修改配置文件禁用 bgc,这样就不会走这些逻辑,从根子上绕过这个问题。

三:总结

说实话在我的dump分析旅程中,这个dump的分析难度还是比较大的,它考验着你对bgc线程底层运作的理解,所幸的是我在调试训练营里用windbg让大家亲眼目睹了后台标记三阶段的详细过程,真是三生有幸!

记一次 .NET某半导体CIM系统 崩溃分析的更多相关文章

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

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

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

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

  3. 记一次 .NET 某医疗器械 程序崩溃分析

    一:背景 1.讲故事 前段时间有位朋友在微信上找到我,说他的程序偶发性崩溃,让我帮忙看下怎么回事,上面给的压力比较大,对于这种偶发性崩溃,比较好的办法就是利用 AEDebug 在程序崩溃的时候自动抽一 ...

  4. 记一次系统崩溃事件【Mac版】

    事件:Mac系统崩溃,导致电脑数据丢失,以及数据安全备份措施的不到位的教训! 解决措施: 1.开机后按:Command+R 按开机键 ,进入Mac 实用工具, 选择磁盘工具.由于没有备份直接抹掉磁盘. ...

  5. linux Kernell crash dump------kdump 的安装设置+Linux系统崩溃的修复解决过程+mysql+kvm

    http://www.ibm.com/developerworks/cn/linux/l-cn-dumpanalyse/https://www.kernel.org/pub/linux/utils/k ...

  6. 构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(34)-文章发布系统①-简要分析

    原文:构建ASP.NET MVC4+EF5+EasyUI+Unity2.x注入的后台管理系统(34)-文章发布系统①-简要分析 系列目录 最新比较闲,为了学习下Android的开发构建ASP.NET ...

  7. Tomcat系统架构分析

    Tomcat系统架构分析 关于这边blog呢,实际开发中并不会用到,但是我觉得还是很有必要认真的写一下.毕竟我们每天在本地撸码的时候使用的就是tomcat来做web服务器.一个常识就是说我们本地在to ...

  8. RHEL6误安装RHEL7的包导致glibc被升级后系统崩溃处理方法

    RHEL6误使用了RHEL7的光盘源,安装了某个RPM包之后,导致glibc被升级,进而导致系统崩溃.   [root@rhel65 ~]# yum install ftp Loaded plugin ...

  9. xx系统属性分析

    在本周的课程学习当中,我们简单了解到系统的一些属性,同时在课下也对<大型网站技术架构:核心原理与案例分析>进行了初步的阅读. 在书籍中我看到了许多其他的知识,也对课堂学习的知识有了巩固,现 ...

  10. Linux系统IO分析工具之iotstat常用参数介绍

    Linux系统IO分析工具之iotstat常用参数介绍 作者:尹正杰 版权声明:原创作品,谢绝转载!否则将追究法律责任. 1>.安装iostat [root@flume115 ~]# yum - ...

随机推荐

  1. NC15445 wyh的吃鸡

    题目链接 题目 题目描述 最近吃鸡游戏非常火,你们wyh学长也在玩这款游戏,这款游戏有一个非常重要的过程,就是要跑到安全区内,否则就会中毒持续消耗血量,我们这个问题简化如下 假设地图为n*n的一个图, ...

  2. Windows也能拥有好用的命令行吗?Powershell+Terminal折腾记录(v1.0版本)

    PS:本文写于2021年,现在已经是2024年,有了很多新变化,我在接下来的文章里会继续更新. 前言 Windows一向以图形化操作入门容易著称,所以对于命令行的支持一直为人所诟病,比起Linux或者 ...

  3. DS18B20数字温度计 (二) 测温, ROM和CRC算法

    目录 DS18B20数字温度计 (一) 电气特性, 寄生供电模式和远距离接线 DS18B20数字温度计 (二) 测温, ROM和CRC算法 DS18B20数字温度计 (三) 1-WIRE总线 ROM搜 ...

  4. 通过performance_schema获取造成死锁的事务语句(转)

    数据库日常维护中我们经常遇到死锁的问题,由于无法获取造成死锁的事务内执行过的语句,对我们死锁的分析造成很大的困难.但是在MySQL 5.7中我们可以利用performance_schema来获取这些语 ...

  5. Maven多模块聚合工程实战

    介绍 本文以SpringCloud微服务多模块聚合案例讲解,全程讲解中间涉及的核心知识点并配图加深理解. 更多maven知识点,建议去看<Maven实战>. 创建父工程 新建maven工程 ...

  6. python 创建动态类

    一般情况下多数是预先定义类 而少数特殊情况就需要去动态创建类了,直接贴代码. class BaseModel(Model): class Meta: database = _tb class_new ...

  7. win32 - 检查权限

    检查当前句柄是否有指定的权限. #include <iostream> #include <windows.h> #include <tchar.h> //#pra ...

  8. LayUI样式优化

    如下是LayUI框架中页面元素的CSS优化样式: /* 表单输入框宽度 */ .layui-form-item .layui-input-inline { width: 295px; } /* 下拉框 ...

  9. Python2升级到Python3

    操作系统环境:CentOS Linux release 7.4.1708 (Core). 系统默认Python版本为2.7. 升级前的版本信息: [root@cch-spider-web1 ~]# l ...

  10. crontab采坑总结

    目录 crontab环境变量 脚本缺少执行权限 crontab是Linux平台实现定时任务的服务工具,通常情况下该服务会预装在发行版中,直接使用即可. 关于crontab的详细用法参考:https:/ ...