C# 托管堆 遭破坏 问题溯源分析 - 一线码农
source link: https://www.cnblogs.com/huangxincheng/p/17072024.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
1. 讲故事
年前遇到了好几例托管堆被损坏的案例,有些运气好一些,从被破坏的托管堆内存现场能观测出大概是什么问题,但更多的情况下是无法做出准确判断的,原因就在于生成的dump是第二现场,借用之前文章的一张图,大家可以理解一下。
为了帮助更多受此问题困扰的朋友,这篇来整理一下如何 快狠准
的抓取第一现场。
二:抓取第一现场
1. 思路分析
要想抓到第一现场,只需要让破坏托管堆的那个线程在修改完之后,回到 CLR Pinvoke 层的时候主动触发GC,因为这时候托管堆已经是损坏状态了,程序也就会立即崩溃,破坏线程也就被捉jian在床,画个图如下:
那如何让 CLR:PInvoke
主动触发GC呢? 这就需要借助微软的 MDA
托管调试助手,它有一个 gcUnmanagedToManaged
配置项就是专门做这件事情的,参考网址:https://learn.microsoft.com/zh-cn/dotnet/framework/debug-trace-profile/gcunmanagedtomanaged-mda
2. 如何配置 MDA
MDA 的配置非常简单,大体上分两步:
- 提交注册表开启MDA
这里使用注册表的方式,需要注意的是,程序和操作系统位数一致的话采用如下方式。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework]
"MDA"="1"
如果不一致,采用如下配置,比如 32bit 程序跑在 64bit 系统上。
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\.NETFramework]
"MDA"="1"
这里我用的是第二段内容,按照官方文档描述,将内容保存到 MDAEnable.reg
中,然后在 注册表编辑器
上导入即可。
- 开启应用程序级捕获
为了能够让 gcUnmanagedToManaged
生效,需要新建应用程序打头的配置文件,比如: Example_16_1_2.exe.mda.config
,内容如下:
<mdaConfig>
<assistants>
<gcUnmanagedToManaged/>
</assistants>
</mdaConfig>
完整截图:
这样就算配置好了,当程序在 PInvoke 时,CLR 会读取注册表的 MDA 值,如果开启的话就会读取 config
中 gcUnmanagedToManaged
子节做相应的逻辑。
tips:如果配置不生效,保守一点的话,建议重启下机器。
3. 一个托管堆破坏的测试案例
为了演示托管堆损坏,我准备将一个 string 传给 C++,然后让 C++ 溢出它来实现托管堆破坏。
C# 代码如下:
namespace Example_16_1_2
{
internal class Program
{
[DllImport("Example_16_1_3.dll", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Unicode)]
public extern static void Alloc(string str);
static void Main(string[] args)
{
Test();
Task.Factory.StartNew(() =>
{
Thread.Sleep(3000);
GC.Collect();
});
Console.ReadLine();
}
static void Test()
{
var str = "hello";
var str2 = "world!";
Alloc(str);
}
}
}
C++ 代码如下:
extern "C"
{
_declspec(dllexport) void Alloc(wchar_t* c);
}
#include "iostream"
#include <Windows.h>
using namespace std;
void Alloc(wchar_t* c)
{
for (size_t i = 0; i < 10; i++)
{
*c++ = 'a';
}
wprintf(L"%s \n", c);
}
从代码逻辑看,只要 Alloc(str)
的线程栈上触发了 GC 就是第一现场,Task 下的 GC.Collect();
是第二现场,如果是前者目的就达到了。
激动人心的时刻到了,把程序跑起来后,由于程序崩溃,procdump 立即给我抓了一个 crash dump,截图如下:
接下来打开 windbg,从序幕信息看果然是 GC 清扫的时候出的问题,托管堆也是损坏状态,信息如下:
Debug session time: Sun Jan 29 10:14:21.000 2023 (UTC + 8:00)
System Uptime: 0 days 1:14:11.423
Process Uptime: not available
.................................
Loading unloaded module list
..
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(4460.52ac): Access violation - code c0000005 (first/second chance not available)
For analysis of this file, run !analyze -v
eax=00610060 ebx=00000000 ecx=02da23a4 edx=00000001 esi=02da2370 edi=02da2388
eip=79a6f2d1 esp=00d3ef64 ebp=00d3f104 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
clr!WKS::gc_heap::plan_phase+0x79b:
79a6f2d1 f70000000080 test dword ptr [eax],80000000h ds:002b:00610060=????????
0:000> !VerifyHeap
Could not request method table data for object 02DA1228 (MethodTable: 0000000C).
Last good object: 02DA121C.
object 03da1020: bad member 02DA1228 at 03DA1098
Last good object: 03DA1010.
object 03da2338: bad member 02DA1228 at 03DA2340
Last good object: 03DA2328.
object 03da3568: bad member 02DA2364 at 03DA357C
Last good object: 03DA3558.
Failed to request SyncBlk at index 1.
那是不是主线程
引发的GC呢?切过去便知。
0:000> ~0s
eax=00610060 ebx=00000000 ecx=02da23a4 edx=00000001 esi=02da2370 edi=02da2388
eip=79a6f2d1 esp=00d3ef64 ebp=00d3f104 iopl=0 nv up ei pl nz na pe nc
cs=0023 ss=002b ds=002b es=002b fs=0053 gs=002b efl=00010206
clr!WKS::gc_heap::plan_phase+0x79b:
79a6f2d1 f70000000080 test dword ptr [eax],80000000h ds:002b:00610060=????????
0:000> !clrstack
OS Thread Id: 0x52ac (0)
Child SP IP Call Site
00d3f220 79a6f2d1 [HelperMethodFrame: 00d3f220] System.StubHelpers.StubHelpers.TriggerGCForMDA()
00d3f294 02bc0aa7 DomainBoundILStubClass.IL_STUB_PInvoke(System.String)
00d3f298 02bc09c9 [InlinedCallFrame: 00d3f298] Example_16_1_2.Program.Alloc(System.String)
00d3f2e0 02bc09c9 Example_16_1_2.Program.Test() [D:\testdump\Example\Example_16_1_2\Program.cs @ 35]
00d3f2f0 02bc0900 Example_16_1_2.Program.Main(System.String[]) [D:\testdump\Example\Example_16_1_2\Program.cs @ 19]
00d3f490 7996f036 [GCFrame: 00d3f490]
0:000> k 10
# ChildEBP RetAddr
00 00d3f104 79a68153 clr!WKS::gc_heap::plan_phase+0x79b
01 00d3f124 79a6847b clr!WKS::gc_heap::gc1+0xbc
02 00d3f13c 79a68585 clr!WKS::gc_heap::garbage_collect+0x367
03 00d3f15c 79b1ddbd clr!WKS::GCHeap::GarbageCollectGeneration+0x1bd
04 00d3f16c 79b1de34 clr!WKS::GCHeap::GarbageCollectTry+0x71
05 00d3f198 79d20aed clr!WKS::GCHeap::GarbageCollect+0xac
06 00d3f204 79d066c0 clr!TriggerGCForMDAInternal+0x7d
07 00d3f28c 02bc0aa7 clr!StubHelpers::TriggerGCForMDA+0x61
WARNING: Frame IP not in any known module. Following frames may be wrong.
08 00d3f2d8 02bc09c9 0x2bc0aa7
09 00d3f2e8 02bc0900 Example_16_1_2!Example_16_1_2.Program.Test+0x39 [D:\testdump\Example\Example_16_1_2\Program.cs @ 35]
0a 00d3f318 7996f036 Example_16_1_2!Example_16_1_2.Program.Main+0x30 [D:\testdump\Example\Example_16_1_2\Program.cs @ 19]
0b 00d3f324 799722da clr!CallDescrWorkerInternal+0x34
0c 00d3f378 7997859b clr!CallDescrWorkerWithHandler+0x6b
0d 00d3f3ec 79b1b11b clr!MethodDescCallSite::CallTargetWorker+0x16a
0e 00d3f510 79b1b7fa clr!RunMain+0x1b3
0f 00d3f77c 79b1b727 clr!Assembly::ExecuteMainMethod+0xf7
从线程栈上的 clr!StubHelpers::TriggerGCForMDA
来看,在 Pinvoke 层果然主动触发了 GC,成功将 Program.Alloc
这个非托管方法捉jian在床。
在此之前很多朋友都会困惑于托管堆破坏导致的程序崩溃,希望这篇文章能够让后来者少走弯路。
Recommend
-
3
1. 讲故事 前段时间有位朋友说他的程序 CPU 出现了暴涨现象,由于程序是买来的,所以问题就比较棘手了,那既然找到我,就想办法帮朋友找出来吧,分析下来,问题比较经典,有必要和大家做一下分享。 二:WinDbg 分...
-
4
1. 讲故事 前段时间遇到了一个难度比较高的 dump,经过几个小时的探索,终于给找出来了,在这里做一下整理,希望对大家有所帮助,对自己也是一个总结,好了,老规矩,上 WinDBG 说话。 二:WinDbg 分析
-
4
C#非托管泄漏中HEAP_ENTRY的Size对不上是怎么回事? ...
-
5
1.讲故事 前几天有位朋友找到我,说他的程序出现了偶发性崩溃,已经抓到了dump文件,Windows事件日志显示的崩溃点在 clr.dll 中,让我帮忙看下是怎么回事,那到底怎么回事呢? 上 WinDbg 说话。 二:WinDbg 分析
-
3
1.讲故事 今天是🐏的第四天,头终于不巨疼了,写文章已经没什么问题,赶紧爬起来写。 这个月初有位朋友找到我,说他的程序出现了CPU爆高,让我帮忙看下怎么回事,简单分析了下有两点比较有意思。 这是一个安全生产的信...
-
2
1. 讲故事 上周有位朋友找到我,说他的 API 被多次调用后出现了内存暴涨,让我帮忙看下是怎么回事?看样子是有些担心,但也不是特别担心,那既然找到我,就给他分析一下吧。 二:WinDbg 分析
-
3
1. 讲故事 上周有位朋友在 github 上向我求助,说线程都被卡住了,让我帮忙看下,截图如下:
-
1
1. 讲故事 前段时间有位朋友找到我,说他的程序内存会出现暴涨,让我看下是怎么事情?而且还告诉我是在 Linux 环境下,说实话在Linux上分析.NET程序难度会很大,难度大的原因在于Linux上的各种开源工具主要是针对 C/C++, 和 .NET 一毛钱关系...
-
2
1. 讲故事 中秋国庆长假结束,哈哈,在老家拍了很多的短视频,有兴趣的可以上B站观看:https://space.bilibili.com/409524162 ,今天继续给大家分享各种奇奇怪怪的.NET...
-
6
1. 讲故事 前几天有位朋友微信上找到我,说他的程序会偶发性崩溃,一直找不到原因,让我帮忙看一下怎么回事,对于这种崩溃类的程序,最好的办法就是丢dump过来看一下便知,话不多说,上windbg说话。 二:WinDbg...
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK