记一次 Windows10 内存压缩模块 崩溃分析
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了记一次 Windows10 内存压缩模块 崩溃分析相关的知识,希望对你有一定的参考价值。
一:背景
1. 讲故事
在给各位朋友免费分析 .NET程序 各种故障的同时,往往也会收到各种其他类型的dump,比如:Windows 崩溃,C++ 崩溃,Mono 崩溃,真的是啥都有,由于基础知识的相对缺乏,分析起来并不是那么的顺利,今天就聊一个 Windows
崩溃的内核dump 吧,这个 dump 是前几天有位朋友给到我的,让我帮忙看一下,有了dump之后上 windbg 分析。
二:WinDbg 分析
1. 从哪里入手
只要是 Windows 平台上的崩溃,操作系统都会维护一个 EXCEPTION_POINTERS
结构体,这个结构体的解读对分析问题非常重要,使用 !analyze -v
命令简要输出如下:
2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
UNEXPECTED_STORE_EXCEPTION (154)
The store component caught an unexpected exception.
Arguments:
Arg1: ffffb402b9851000, Pointer to the store context or data manager
Arg2: ffffe607bc53df30, Exception information
Arg3: 0000000000000002, Reserved
Arg4: 0000000000000000, Reserved
...
EXCEPTION_RECORD: ffffe607bc53eeb8 -- (.exr 0xffffe607bc53eeb8)
ExceptionAddress: fffff80025b04bd0 (nt!RtlDecompressBufferXpressLz+0x0000000000000050)
ExceptionCode: c0000006 (In-page I/O error)
ExceptionFlags: 00000000
NumberParameters: 3
Parameter[0]: 0000000000000000
Parameter[1]: 0000023f30ee99f0
Parameter[2]: 00000000c0000185
Inpage operation failed at 0000023f30ee99f0, due to I/O error 00000000c0000185
EXCEPTION_PARAMETER1: 0000000000000000
EXCEPTION_PARAMETER2: 0000023f30ee99f0
CONTEXT: ffffe607bc53e6f0 -- (.cxr 0xffffe607bc53e6f0)
rax=fffff80025b04b80 rbx=ffff9d808d7fa000 rcx=ffff9d808d7fa000
rdx=ffff9d808d7fa000 rsi=0000000000000002 rdi=0000023f30ee99f0
rip=fffff80025b04bd0 rsp=ffffe607bc53f0f8 rbp=0000023f30eea2fe
r8=0000023f30ee99f0 r9=0000000000000964 r10=ffff9d808d7faea0
r11=0000023f30eea354 r12=ffffe607bc53f368 r13=ffffb402d84d8000
r14=ffff9d808d7fb000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
nt!RtlDecompressBufferXpressLz+0x50:
fffff800`25b04bd0 418b08 mov ecx,dword ptr [r8] ds:002b:0000023f`30ee99f0=????????
Resetting default scope
...
从卦中信息看,是由于将地址 0000023f30ee99f0
所映射的物理内存页换入到内存中,抛了一个IO错误,从汇编指令 ecx,dword ptr [r8] ds:002b:0000023f30ee99f0=????????
上也能看的出来。
如果大家不信,可以用 !vtop
和 !pte
观察下它们对应的物理地址和物理页号,都是找不到的。
2: kd> !vtop 0 000000006d34aca0
Amd64VtoP: Virt 000000006d34aca0, pagedir 00000003d81fb002
Amd64VtoP: PML4E 00000003d81fb002
Amd64VtoP: PML4E read error 0x8000FFFF
Virtual address 6d34aca0 translation fails, error 0x8000FFFF.
2: kd> !pte 000000006d34aca0
VA 000000006d34aca0
PXE at FFFF86432190C000 PPE at FFFF864321800008 PDE at FFFF864300001B48 PTE at FFFF860000369A50
contains 0000000000000000
contains 0000000000000000
not valid
2. 洞察异常前的线程栈
有了这个初步信息之后,接下来就来观察异常时的寄存器上下文和线程栈信息,输出如下:
2: kd> .cxr 0xffffe607bc53e6f0 ; k
rax=fffff80025b04b80 rbx=ffff9d808d7fa000 rcx=ffff9d808d7fa000
rdx=ffff9d808d7fa000 rsi=0000000000000002 rdi=0000023f30ee99f0
rip=fffff80025b04bd0 rsp=ffffe607bc53f0f8 rbp=0000023f30eea2fe
r8=0000023f30ee99f0 r9=0000000000000964 r10=ffff9d808d7faea0
r11=0000023f30eea354 r12=ffffe607bc53f368 r13=ffffb402d84d8000
r14=ffff9d808d7fb000 r15=0000000000000000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0000 ds=002b es=002b fs=0053 gs=002b efl=00050246
nt!RtlDecompressBufferXpressLz+0x50:
fffff800`25b04bd0 418b08 mov ecx,dword ptr [r8] ds:002b:0000023f`30ee99f0=????????
*** Stack trace for last set context - .thread/.cxr resets it
# Child-SP RetAddr Call Site
00 ffffe607`bc53f0f8 fffff800`25a5bc10 nt!RtlDecompressBufferXpressLz+0x50
01 ffffe607`bc53f110 fffff800`25a5bb14 nt!RtlDecompressBufferEx+0x60
02 ffffe607`bc53f160 fffff800`25a5b9a1 nt!ST_STORE<SM_TRAITS>::StDmSinglePageCopy+0x150
03 ffffe607`bc53f220 fffff800`25b56ff0 nt!ST_STORE<SM_TRAITS>::StDmSinglePageTransfer+0xa5
04 ffffe607`bc53f270 fffff800`25b57904 nt!ST_STORE<SM_TRAITS>::StDmpSinglePageRetrieve+0x180
05 ffffe607`bc53f310 fffff800`25b57aed nt!ST_STORE<SM_TRAITS>::StDmPageRetrieve+0xc8
06 ffffe607`bc53f3c0 fffff800`25a5c071 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue+0x85
07 ffffe607`bc53f440 fffff800`25aad478 nt!SMKM_STORE<SM_TRAITS>::SmStDirectReadCallout+0x21
08 ffffe607`bc53f470 fffff800`25a5cb57 nt!KeExpandKernelStackAndCalloutInternal+0x78
09 ffffe607`bc53f4e0 fffff800`25a5713c nt!SMKM_STORE<SM_TRAITS>::SmStDirectRead+0xc7
0a ffffe607`bc53f5b0 fffff800`25a56b70 nt!SMKM_STORE<SM_TRAITS>::SmStWorkItemQueue+0x1ac
0b ffffe607`bc53f600 fffff800`25b58727 nt!SMKM_STORE_MGR<SM_TRAITS>::SmIoCtxQueueWork+0xc0
0c ffffe607`bc53f690 fffff800`25b2b94b nt!SMKM_STORE_MGR<SM_TRAITS>::SmPageRead+0x167
0d ffffe607`bc53f700 fffff800`25ad1020 nt!SmPageRead+0x33
0e ffffe607`bc53f750 fffff800`25ad023d nt!MiIssueHardFaultIo+0x10c
0f ffffe607`bc53f7a0 fffff800`25a6e818 nt!MiIssueHardFault+0x29d
10 ffffe607`bc53f860 fffff800`25c0b6d8 nt!MmAccessFault+0x468
11 ffffe607`bc53fa00 00007ff8`c3089fa2 nt!KiPageFault+0x358
12 00000067`4ca7f270 00000000`00000000 0x00007ff8`c3089fa2
从卦中的调用栈信息看,代码的源头是 用户态 (0x00007ff8c3089fa2)
过来的,应该是访问用户态地址 0000023f30ee99f0
上的内容,由于对应的物理页不在内存中,触发了 nt!KiPageFault
中断,也就是 idt 表中的 0xe
号标记的 缺页中断, 输出如下:
lkd> !idt
Dumping IDT: fffff8050ce87000
00: fffff80506206400 nt!KiDivideErrorFault
...
0e: fffff80506209980 nt!KiPageFault
在缺页中断中触发了 IO 操作 MiIssueHardFaultIo
要从pagefiles 中捞页面,接下来就是页读取逻辑 SmPageRead
,最后在 RtlDecompressBufferXpressLz
中引发了蓝屏。
如果心比较细的话,你会发现有一个关键词 Decompress
,对,就是解压缩,为什么换入的page还要解压缩呢? 这就是我们的突破点。
3. 为什么会解压缩
要找到这个问题的答案,需要观察下这个异常线程的详细信息,可以用 .thread
切到异常的线程上下文,再用 !thread
观察。
2: kd> .thread
Implicit thread is now ffffb402`be04a080
2: kd> !thread ffffb402`be04a080
THREAD ffffb402be04a080 Cid 0594.2228 Teb: 000000674c5b8000 Win32Thread: 0000000000000000 RUNNING on processor 2
Not impersonating
GetUlongFromAddress: unable to read from fffff8002641152c
Owning Process ffffb402b8d58080 Image: <Invalid process>
Attached Process ffffb402b984a040 Image: MemCompression
fffff78000000000: Unable to get shared data
Wait Start TickCount 649763
Context Switch Count 9 IdealProcessor: 0
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address 0x00007ff8c808afb0
Stack Init ffffe607bc53fb90 Current ffffe607bc53e800
Base ffffe607bc540000 Limit ffffe607bc539000 Call 0000000000000000
Priority 8 BasePriority 7 PriorityDecrement 0 IoPriority 2 PagePriority 2
Child-SP RetAddr : Args to Child : Call Site
ffffe607`bc53de78 fffff800`25d9856e : 00000000`00000154 ffffb402`b9851000 ffffe607`bc53df30 00000000`00000002 : nt!KeBugCheckEx
ffffe607`bc53de80 fffff800`25c189db : ffffb402`b9851000 ffffe607`bc53df30 ffffe607`00000002 ffffe607`bc53dfe0 : nt!SMKM_STORE<SM_TRAITS>::SmStUnhandledExceptionFilter+0x7e
ffffe607`bc53ded0 fffff800`25bcfb1f : fffff800`00000002 fffff800`258d905c ffffe607`bc539000 ffffe607`bc540000 : nt!`SMKM_STORE<SM_TRAITS>::SmStDirectReadIssue\'::`1\'::filt$0+0x22
ffffe607`bc53df00 fffff800`25c062ff : fffff800`258d905c ffffe607`bc53e4e0 fffff800`25bcfa80 00000000`00000000 : nt!_C_specific_handler+0x9f
...
从卦中信息看,异常线程还有一个附加的进程 ffffb402b984a040
,来自于 MemCompression
模块,从名字上看所谓的 压缩解压缩
逻辑应该和它有关系,接下来到网上去搜一下,有一篇文章说的非常好: https://www.howtogeek.com/319933/what-is-memory-compression-in-windows-10/
大意:这是 Windows10 新增的一个功能,用内存压缩技术让RAM中可以存储更多的内存页,相比传统的交换到 PageFiles.sys 有更高的性能,缺点就是需要耗费一些解压缩需要的 CPU 时间。
在 Windows10 上也能窥探一二:
4. 问题解决
解决办法很简单,学 4S 店的问题解决之道,能换的就坚决不修,让朋友把 内存压缩
给关掉,这样就不走
RtlDecompressBufferXpressLz
逻辑,理论上就不会有什么问题了。
关闭之后,据朋友反馈,这几天没有崩溃了。
三:总结
分析内核态相比用户态难度要大的多,需要对操作系统
以及CPU
的相关知识有一个比较深度的理解,任重道远。。。
再记一次Memory Leak分析
性能是优化出来的,不管是在上生产前,还是在上生产后。大部分性能在性能测试阶段就能发现问题,但也有一些性能问题,结合生产的环境,生产数据才能表现出来,成为一个显著的瓶颈。
这次是生成pdf造成的内存泄露,大体代码如下,具体表现是内存缓慢增长,在docker中比windows增长速度要快,但都有只增不回收的特点。
using System.Data;
using System.Reflection.Metadata;
using QuestPDF.Helpers;
using QuestPDF.Infrastructure;
using QuestPDF.Fluent;
using QRCoder;
using Microsoft.AspNetCore.Mvc;
using QuestPDF.Drawing;
using QuestPDF;
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/getpdf", () =>
var table = new DataTable();
for (var i = 0; i < 10; i++)
table.Columns.Add(i.ToString());
for (var row = 0; row < 1000; row++)
table.Rows.Add(row.ToString(), row.ToString(), row.ToString(), row.ToString(), row.ToString(), row.ToString(), row.ToString(), DateTime.Now + "wwewrwerewfdsfdswefwefewfwefwefew" + row, row.ToString(), row.ToString());
return TypedResults.File(GetPDF(table), contentType: "application/pdf", fileDownloadName: "a.pdf");
);
app.Run();
static IContainer CellStyle(IContainer container)
return container.DefaultTextStyle(x => x.SemiBold().FontSize(11)).PaddingVertical(5).BorderBottom(1).BorderColor(Colors.Black);
static byte[] GetPDF(DataTable dt)
var doc = QuestPDF.Fluent.Document.Create(container =>
using var stream = File.OpenRead(Path.Combine(AppDomain.CurrentDomain.BaseDirectory, "fonts", "MEIRYO.TTC"));
FontManager.RegisterFont(stream);
Settings.EnableCaching = true;
Settings.EnableDebugging = false;
container.Page(page =>
page.Size(PageSizes.A4);
page.Margin(2, Unit.Centimetre);
page.PageColor(Colors.White);
page.DefaultTextStyle(x => x.FontSize(14).FontFamily("Meiryo"));
page.Content()
.PaddingVertical(1, Unit.Centimetre)
.Column(x =>
x.Item().Table(table =>
table.ColumnsDefinition(columns =>
for (var i = 0; i < dt.Columns.Count; i++)
columns.RelativeColumn();
);
table.Header(header =>
foreach (DataColumn col in dt.Columns)
header.Cell().Element(CellStyle).Text(col.ColumnName);
);
foreach (DataRow row in dt.Rows)
for (var i = 0; i < dt.Columns.Count; i++)
if (i == 7)
byte[] qrCodeAsBitmapByteArr = PngByteQRCodeHelper.GetQRCode(row[i].ToString(), QRCodeGenerator.ECCLevel.Q, 20, false);
using var ms = new MemoryStream(qrCodeAsBitmapByteArr);
table.Cell().Image(qrCodeAsBitmapByteArr);
else
table.Cell().Element(CellStyle).Text(row[i].ToString());
);
);
page.Footer()
.AlignCenter()
.Text(x =>
x.Span("Page ");
x.CurrentPageNumber();
x.Span("/ ");
x.TotalPages();
);
);
);
return doc.GeneratePdf();
各种.net的调试工具用上,都只能证明内存只增不减,连pmap都用上了,发现下面的一个大文件的内存占用,并且很多,大体都是在65M左右。
Address Kbytes RSS Dirty Mode Mapping
00007f4d54000000 65536 65536 65536 rw--- [ anon ]
经过一天的测试,找不到具体的问,最后推测是生成Pdf后,生成的内存是非托管内存,GC回收不掉,每当有用户下载PDF时,就会积累内存,直到Pod崩掉。
干不掉bug,就干掉需求吧,因为经过统计这个下载pdf的使用量很低,可以下掉功能。同时把这个问题给QuestPDF提了个issues。就准备躺平。QuestPDF回应很快,说注册字体只用注册一次就行,多次注册会重复累加字体,37到40行代码,只在服务启动时加载一次即可,经过测试果然有效果。
在复盘时,总结,常规的思维在win下注册字体,多次注册不会让相同的字体保存多份,从而认知QuestPDF注册也是同理,造成下载一次就注册一次,造成内存积加,这也是为什么65M左右的内存一起在累加的原因。
后来,我又思考了一下,如果做一个支持高并发,高性能的web服务,像下载Excel,PDF这些操作,是不能在后台生成的,因为用户的一个文件的体积和用户的数据是有关系的,大小很难控件,如果耦合在web服务端来做这件事,肯定是个“雷”。也有的建议是用其他服务或cli异步生成,然后放在云存储上让用户下载,这也是一种解决方案。
我觉还是让web服务做自己擅长的事,提供数据,把文件生成组装操作转嫁给客户的浏览器来完成,这样既能减轻web服务的负载,又能充分利用客户端的资源,一举两得。
以上是关于记一次 Windows10 内存压缩模块 崩溃分析的主要内容,如果未能解决你的问题,请参考以下文章