记一次 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 上也能窥探一二:

记一次 Windows10 内存压缩模块 崩溃分析

4. 问题解决

解决办法很简单,学 4S 店的问题解决之道,能换的就坚决不修,让朋友把 内存压缩 给关掉,这样就不走
RtlDecompressBufferXpressLz 逻辑,理论上就不会有什么问题了。

记一次 Windows10 内存压缩模块 崩溃分析

关闭之后,据朋友反馈,这几天没有崩溃了。

三:总结

分析内核态相比用户态难度要大的多,需要对操作系统以及CPU的相关知识有一个比较深度的理解,任重道远。。。

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

本站文章如无特殊说明,均为本站原创,如若转载,请注明出处:记一次 Windows10 内存压缩模块 崩溃分析 - Python技术站

(0)
上一篇 2023年5月2日
下一篇 2023年5月3日

相关文章

  • VS2022使用ClickOnce发布程序本地安装.net框架

    因为遇到下面的错误,没有在网上搜到详细解决问题的教程,费了一些时间才解决了问题,特此记录一下,也希望能帮助到其他人。  要在“系统必备”对话框中启用“从与我的应用程序相同的位置下载系统必备组件”,必须将“.NET 桌面运行时 6.0.14 (x64)”项的文件“net6desktopruntime_x64\windowsdesktop-runtime-6.0…

    C# 2023年5月7日
    00
  • C#实现的AES加密解密完整实例

    C#实现的AES加密解密,是一种常见的加密方式,下面我将详细讲解实现AES加密解密的完整攻略,包括示例说明。 什么是AES加密解密? AES是一种对称加密算法,它能够通过一个密钥,对一段数据进行加密和解密。AES算法可以使用不同的密钥长度(128、192和256位),密钥越长,加密越强大,但是也越慢。 C#实现AES加密解密的基本步骤 引入命名空间:usin…

    C# 2023年6月7日
    00
  • .net core日志结构化

    .NET Core日志结构化攻略 在.NET Core中,日志是一种重要的调试和故障排除工具。日志结构化是一种将日志消息转换为结构化数据的技术,可以提高日志的可读性和可搜索性。本攻略将介绍如何在.NET Core中实现日志结构化,并提供两个示例说明。 实现日志结构化 在.NET Core中,我们可以使用以下类来实现日志结构化: 1. ILogger ILog…

    C# 2023年5月17日
    00
  • C#实现的序列化通用类实例

    C#实现的序列化通用类实例 介绍 在C#中,序列化是将对象转换为流的过程,以便将其存储在磁盘或通过网络传输。反序列化则是将对象流转换回对象的过程。序列化通用类是一个可以将对象序列化为数据流或从数据流中反序列化的类,它可用于序列化不同类型的对象。 实现过程 创建配置文件(可选) 在整个应用程序中,配置文件非常重要,它包含着我们程序的基本配置信息。序列化通用类也…

    C# 2023年6月6日
    00
  • C#控制台基础 list<>初始化的两种方法

    C#中的list是一种通用的、可动态调整的数据结构,通过它可以方便地存储和操作数据。在控制台程序中,初始化list最常见的两种方式是使用构造函数和使用集合初始化器。 使用构造函数初始化list list的构造函数可以接受任何实现IEnumerable接口的对象,它会根据传入的元素类型自动推断出泛型参数类型。下面是使用构造函数初始化list的示例代码: Lis…

    C# 2023年6月1日
    00
  • C# 字节数组、各进制字符串数据互转

    前言 日常开发过程中,格式转换是必不可少的重要环节,经常是十进制转十六进制、十六进制转byte数组又转换回来来回转换,最然进制转换很基础同时 C# 也提供了很多直接方便进行格式转换的方法,但是封装一个工具类会方便很多,不用每次都手写代码逻辑,之前一直都是简单的自己写,稍复杂的就用前辈写好的直接调用,这次自己写一个。 简单的定义为一行代码完事,多一行都不写?。…

    C# 2023年5月5日
    00
  • asp.net(C#)实现功能强大的时间日期处理类完整实例

    asp.net(C#)实现功能强大的时间日期处理类完整实例 引言 在程序开发过程中,日期和时间处理是非常常见且重要的操作,然而C#在对时间日期的处理上提供了很多内置的功能和类,但是并不一定适合所有的场景。因此,本文介绍如何实现功能强大的时间日期处理类,让我们的开发变得更加高效。 步骤 创建一个新的C#类,在类中定义所需要的方法和变量。 “`csharp p…

    C# 2023年6月1日
    00
  • 12306动态验证码启发之ASP.NET实现动态GIF验证码(附源码)

    让我来详细解释一下“12306动态验证码启发之ASP.NET实现动态GIF验证码(附源码)”这篇文章的完整攻略。 1. 研究动态验证码的实现原理 首先,我们需要对动态验证码的实现原理进行研究。动态验证码是指每次刷新页面都会显示不同的验证码图片,这种验证码的安全性更高,因为攻击者无法通过简单地截取验证码的图片进行破解。而实现动态验证码的关键就是生成动态的图像。…

    C# 2023年6月3日
    00
合作推广
合作推广
分享本页
返回顶部