首页 > 其他分享 >蓝屏分析

蓝屏分析

时间:2024-05-18 17:18:40浏览次数:15  
标签:分析 BUGCHECK 00000000 Value Key 蓝屏 nt MyDriver10

04蓝屏分析

直接上蓝屏代码

#include <ntifs.h>

VOID Unload(PDRIVER_OBJECT pDriver)
{
	DbgPrint("Driver Unload\r\n");
}

NTSTATUS DriverEntry(PDRIVER_OBJECT pDriver, PUNICODE_STRING pReg)
{
	pDriver->DriverUnload = Unload;
	//DbgBreakPoint();
	DbgPrint("Driver Load\r\n");
	int* x = 0;//指针x指向的是地址0x00000000
	*x = 100;//向0x00000000地址处写入100数据,会引发异常
	return STATUS_SUCCESS;
}

这里可以看到指针x指向的是0x00000000

单步一下,崩掉了

kd> p

*** Fatal System Error: 0x0000007e
                       (0xC0000005,0xAE916026,0x91776904,0x91776370)


A fatal system error has occurred.
Debugger entered on first try; Bugcheck callbacks have not been invoked.

A fatal system error has occurred.

nt!RtlpBreakWithStatusInstruction:
8406bd8c cc              int     3

双机调试

这里我是用的原版Windbg不知道为什么总是出不来!analysize -v所以我又用Windbg Preview调了一下,下面是Windbg Preview!analyze -v输出信息

kd> !analyze -v
Connected to Windows 7 7601 x86 compatible target at (Sat Jan  7 21:09:04.397 2023 (UTC + 8:00)), ptr64 FALSE
Loading Kernel Symbols
.............

Press ctrl-c (cdb, kd, ntsd) or ctrl-break (windbg) to abort symbol loads that take too long.
Run !sym noisy before .reload to track down problems loading symbols.

..................................................
................................................................
.................................
Loading User Symbols

Loading unloaded module list
............
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED (7e)
This is a very common BugCheck.  Usually the exception address pinpoints
the driver/function that caused the problem.  Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: c0000005, The exception code that was not handled
Arg2: b42bf025, The address that the exception occurred at
Arg3: 9344890c, Exception Record Address
Arg4: 93448370, Context Record Address

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : AV.Dereference
    Value: NullPtr

    Key  : AV.Fault
    Value: Write

    Key  : Analysis.CPU.mSec
    Value: 1077

    Key  : Analysis.DebugAnalysisManager
    Value: Create

    Key  : Analysis.Elapsed.mSec
    Value: 174659

    Key  : Analysis.IO.Other.Mb
    Value: 4

    Key  : Analysis.IO.Read.Mb
    Value: 1

    Key  : Analysis.IO.Write.Mb
    Value: 7

    Key  : Analysis.Init.CPU.mSec
    Value: 1874

    Key  : Analysis.Init.Elapsed.mSec
    Value: 137328

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 78

    Key  : Bugcheck.Code.DumpHeader
    Value: 0x7e

    Key  : Bugcheck.Code.KiBugCheckData
    Value: 0x7e

    Key  : WER.OS.Branch
    Value: win7sp1_ldr_escrow

    Key  : WER.OS.Timestamp
    Value: 2018-03-30T16:00:00Z

    Key  : WER.OS.Version
    Value: 7.1.7601.24094


BUGCHECK_CODE:  7e

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: ffffffffb42bf025

BUGCHECK_P3: ffffffff9344890c

BUGCHECK_P4: ffffffff93448370

EXCEPTION_RECORD:  9344890c -- (.exr 0xffffffff9344890c)
ExceptionAddress: b42bf025 (MyDriver10!DriverEntry+0x00000025)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 00000001
   Parameter[1]: 00000000
Attempt to write to address 00000000

CONTEXT:  93448370 -- (.cxr 0xffffffff93448370)
eax=00000000 ebx=00000000 ecx=00000000 edx=0000000d esi=88980a98 edi=87162000
eip=b42bf025 esp=934489d4 ebp=934489d8 iopl=0         nv up ei ng nz na pe nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010286
MyDriver10!DriverEntry+0x25:
b42bf025 c70164000000    mov     dword ptr [ecx],64h  ds:0023:00000000=????????
Resetting default scope

PROCESS_NAME:  System

WRITE_ADDRESS:  00000000 

ERROR_CODE: (NTSTATUS) 0xc0000005 - 0x%p            0x%p                    %s

EXCEPTION_CODE_STR:  c0000005

EXCEPTION_PARAMETER1:  00000001

EXCEPTION_PARAMETER2:  00000000

EXCEPTION_STR:  0xc0000005

STACK_TEXT:  
934489d8 84212986     88980a98 87162000 00000000 MyDriver10!DriverEntry+0x25 [C:\Users\MuRKuo\source\repos\MyDriver10\main.c @ 14] 
93448bbc 841faaa0     00000001 00000000 93448be4 nt!IopLoadDriver+0x7ed
93448c00 840b43e3     83b59bd0 00000000 8894f9c0 nt!IopLoadUnloadDriver+0x70
93448c50 84241906     80000001 a9cb5ac9 00000000 nt!ExpWorkerThread+0x10d
93448c90 840e2e0d     840b42d6 80000001 00000000 nt!PspSystemThreadStartup+0x9e
00000000 00000000     00000000 00000000 00000000 nt!KiThreadStartup+0x19


FAULTING_SOURCE_LINE:  C:\Users\MuRKuo\source\repos\MyDriver10\main.c

FAULTING_SOURCE_FILE:  C:\Users\MuRKuo\source\repos\MyDriver10\main.c

FAULTING_SOURCE_LINE_NUMBER:  14

FAULTING_SOURCE_CODE:  
    10: 	pDriver->DriverUnload = Unload;
    11: 	//DbgBreakPoint();
    12: 	DbgPrint("Driver Load\r\n");
    13: 	int* x = 0;//????x???¨°???????¡¤0x00000000
>   14: 	*x = 100;//?¨°0x00000000???¡¤??????100???????¨¢??¡¤??¨¬??
    15: 	return STATUS_SUCCESS;
    16: }


SYMBOL_NAME:  MyDriver10!DriverEntry+25

MODULE_NAME: MyDriver10

IMAGE_NAME:  MyDriver10.sys

STACK_COMMAND:  .cxr 0xffffffff93448370 ; kb

FAILURE_BUCKET_ID:  0x7E_MyDriver10!DriverEntry+25

OS_VERSION:  7.1.7601.24094

BUILDLAB_STR:  win7sp1_ldr_escrow

OSPLATFORM_TYPE:  x86

OSNAME:  Windows 7

FAILURE_ID_HASH:  {f7940179-d75c-5c40-e993-537b8464fd03}

Followup:     MachineOwner
---------

可以清楚的看到导致系统崩掉的驱动详细信息

BugCode 7e (有源代码)

转储文件分析

我们g一下让他继续运行

可以看到现在正在dump内存

等他dump完会输出complete

之后我们让虚拟机重启

去虚拟机的控制面板->系统和安全->系统

按照如上步骤可以找到存储的崩溃转储文件

我这个核心内存转储的dmp文件在Windbg中打开后基本和直接调试是没啥区别的,除了标题换成了本地,其他的基本没变化

这里我们假装这个转储不正确,手动调试一下看看

kd> r //查看寄存器
eax=841878e4 ebx=00000000 ecx=00000003 edx=00000000 esi=80b96120 edi=00000000
eip=8412b3b8 esp=93448218 ebp=93448230 iopl=0         nv up ei pl nz na po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00000202
nt!KeBugCheckEx+0x1e:
8412b3b8 cc              int     3
kd> dds 93448218 //树形打印从esp开始的栈
VirtualToOffset: 93448218 not properly sign extended
93448218  0000007e
9344821c  c0000005
93448220  b42bf025 MyDriver10!DriverEntry+0x25 [C:\Users\MuRKuo\source\repos\MyDriver10\main.c @ 14]
93448224  9344890c
93448228  93448370
9344822c  00000000
93448230  93448c90
93448234  84241946 nt!PspSystemThreadStartup+0xde
93448238  0000007e
9344823c  c0000005
93448240  b42bf025 MyDriver10!DriverEntry+0x25 [C:\Users\MuRKuo\source\repos\MyDriver10\main.c @ 14]
93448244  9344890c
93448248  93448370
9344824c  840b10e4 nt!_EH4_CallFilterFunc+0x12
93448250  00000000
93448254  93448c90
93448258  840a70d0 nt! ?? ::FNODOBFM::`string'+0x3270
9344825c  93448284
93448260  8410ee85 nt!_except_handler4+0x8e
93448264  00000000
93448268  00000000
9344826c  00000000
93448270  9344890c
93448274  93448370
93448278  840a70e0 nt! ?? ::FNODOBFM::`string'+0x3280
9344827c  00000001
93448280  00056000
93448284  934482a8
93448288  840aede2 nt!ExecuteHandler2+0x26
9344828c  fffffffe
93448290  93448c80
93448294  93448370

这里我们先获取了崩溃前的ESP的值,然后通过dds指令(树形排列堆栈)的方式获取崩溃前的栈中的情况

从中栈的底部可以很明显的看到崩溃前执行的驱动信息等,例如下面这段

93448220  b42bf025 MyDriver10!DriverEntry+0x25 [C:\Users\MuRKuo\source\repos\MyDriver10\main.c @ 14]

从中就可以看到最后执行到了我们驱动的第14行,而驱动源文件的第14行也确实是崩溃的地方

	*x = 100;//向0x00000000地址处写入100数据,会引发异常

使用!analyze -v可以看到一堆的信息输出

其中有一行BugCheck_Code

这时候可以去微软官方查找一下这是什么错误

https://learn.microsoft.com/zh-cn/windows-hardware/drivers/debugger/bug-check-code-reference2

从中就可以得到关于这个崩溃的一些详细信息

根据如下的参数,可以去Windbg看每个参数对应了什么

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED参数

参数 说明
1 未处理的异常代码。
2 发生异常的地址。
3 异常记录的地址。
4 上下文记录的地址。
BUGCHECK_CODE:  7e

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: ffffffffb42bf025

BUGCHECK_P3: ffffffff9344890c

BUGCHECK_P4: ffffffff93448370

其中P1-P4和上图的参数对应

可以看到对应的代码出错的地方

这个有源代码比较简单就不看了

BugCode 8e

看一下转储文件的BugCode

FILE_IN_CAB:  032821-18891-01.dmp

BUGCHECK_CODE:  8e

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: ffffffff83ee33f5

BUGCHECK_P3: ffffffff8376765c

BUGCHECK_P4: 0

先去官网看一下对应的参数

KERNEL_MODE_EXCEPTION_NOT_HANDLED 参数

参数 说明
1 未处理的异常代码
2 发生异常的地址
3 捕获帧
4 保留

看一下发生异常的地址

根据官方的如下说明

KERNEL_MODE_EXCEPTION_NOT_HANDLED bug 检查是一个非常常见的 bug 检查。 若要对其进行解释,必须确定生成的具体异常。

常见的异常代码包括:

  • 0x80000002: STATUS_DATATYPE_MISALIGNMENT 指示遇到了未对齐的数据引用。
  • 0x80000003: STATUS_BREAKPOINT 指示在没有内核调试器附加到系统时遇到断点或断言。
  • 0xC0000005: STATUS_ACCESS_VIOLATION 指示发生了内存访问冲突。

这里可以对应上我们的BugCode的P1的BUGCHECK_P1: ffffffffc0000005

也就是C005

说明是发生了内存访问冲突

总之这个转储文件反映出的问题就是在ffffffff83ee33f5地址处出现了内存访问冲突

83ee33f5 8b0a            mov     ecx,dword ptr [edx]  ds:0023:00000124=????????

Windbg也写得很清楚,[EAX]中的值没有读取到,原因是出现了内存访问冲突

同时这里也可以去ntkrnlpa里面看一下

BugCode 7e

对应一下参数

BUGCHECK_CODE:  7e

BUGCHECK_P1: ffffffffc0000005

BUGCHECK_P2: ffffffff84043f7c

BUGCHECK_P3: ffffffff8d7036f8

BUGCHECK_P4: ffffffff8d703160
参数 说明
1(ffffffffc0000005) 未处理的异常代码。
2(ffffffff84043f7c) 发生异常的地址。
3(ffffffff8d7036f8) 异常记录的地址。
4(ffffffff8d703160) 上下文记录的地址。

异常代码

常见的未经处理的异常代码

  • 0x80000002:STATUS_DATATYPE_MISALIGNMENT表示遇到未对齐的数据引用。
  • 0x80000003:STATUS_BREAKPOINT指示未将内核调试器附加到系统时遇到断点或 ASSERT。
  • 0xC0000005:STATUS_ACCESS_VIOLATION指示发生了内存访问冲突。

这次还是内存访问冲突

发生异常的地方

nt!SeCreateAccessStateEx+0x9b:
84043f7c a5              movs    dword ptr es:[edi],dword ptr [esi] es:0023:8d7038bc=00000000 ds:0023:00000034=????????

可以发现是取[esi]的值取不到

接下来看一下栈

kd> kv
 # ChildEBP RetAddr      Args to Child              
00 8d7037d0 84043ed8     85ee5798 85ec9920 8d703840 nt!SeCreateAccessStateEx+0x9b
01 8d7037f0 84092d30     8d703840 8d7038b8 00000000 nt!SeCreateAccessState+0x28
02 8d703980 971d5115     8d7039a8 00000040 00000000 nt!ObReferenceObjectByName+0x8f
WARNING: Stack unwind information not available. Following frames may be wrong.
03 8d7039b8 971d5064     971d5284 00220020 971d525c 122+0x1115
04 8d7039d8 83fe02e6     8728fe10 876ec000 00000000 122+0x1064
05 8d703bbc 83fe3d98     00000001 00000000 8d703be4 nt!IopLoadDriver+0x7ed
06 8d703c00 83e99aab     97b37bd0 00000000 85ee5798 nt!IopLoadUnloadDriver+0x70
07 8d703c50 84025f5e     00000001 2734038b 00000000 nt!ExpWorkerThread+0x10d
08 8d703c90 83ecd219     83e9999e 00000001 00000000 nt!PspSystemThreadStartup+0x9e
09 00000000 00000000     00000000 00000000 00000000 nt!KiThreadStartup+0x19

发现其中有两行这个

03 8d7039b8 971d5064     971d5284 00220020 971d525c 122+0x1115
04 8d7039d8 83fe02e6     8728fe10 876ec000 00000000 122+0x1064

这个112就代表当时加载的驱动的基地址后面+0x1115是驱动出错的代码的偏移

例如PE程序的起始地址是0x00400000

那么这个驱动(驱动是PE结构的)崩溃的代码位置就是0x00400000 + 0x1115 = 0x00401237

然后这个驱动调用了ObReferenceObjectByName进而nt!SeCreateAccessState+0x28最后地址不对,然后系统挂掉

诡异的蓝屏-1

#include <ntifs.h>

VOID Unload(PDRIVER_OBJECT pDriver)
{
	DbgPrint("Driver Unload\r\n");
}

NTSTATUS DriverEntry(PDRIVER_OBJECT pDriver, PUNICODE_STRING pReg)
{
	char buf[0x100000000] = { 0 };//内核栈爆了
	int x = 0;
	pDriver->DriverUnload = Unload;
	//DbgBreakPoint();
	return STATUS_SUCCESS;
}

这段代码我编译的时候显示数组过大,但是可以编译通过

编译完后虚拟机里一运行就蓝

原因是内核栈爆了,内核栈一共是12K,也就是4096 * 12

这种错误会导致蓝屏的BugCheckCode经常变动,第一次可能是7e,第二次可能就是50了,而且不一定是一加载就崩溃,我写的这个程序由于是在入口这直接开辟超大空间,直接把栈顶爆了,所以才一加载就出问题有的时候栈是一点点顶爆的,可能需要挺长的时候才会蓝屏

栈炸了停留的位置一般是不一样的

诡异的蓝屏-2

#include <ntifs.h>

VOID Unload(PDRIVER_OBJECT pDriver)
{
	DbgPrint("unload\r\n");
}
VOID
vStart(
	_In_ PVOID StartContext
)
{
	*(int*)PsCreateSystemThread = 100;
	//这里可以写创建新线程后,新线程要做的事
}
NTSTATUS DriverEntry(PDRIVER_OBJECT pDriver, PUNICODE_STRING pReg)
{
	pDriver->DriverUnload = Unload;
	//DbgBreakPoint();
	HANDLE hThread = NULL;
	NTSTATUS status = PsCreateSystemThread(&hThread, THREAD_ALL_ACCESS, NULL, NULL, NULL, vStart, NULL);//创建线程
	if (NT_SUCCESS(status))
	{
		ZwClose(hThread);//释放线程句柄
	}
	return STATUS_SUCCESS;
}

这里由于想写PsCreateSystemThread的函数地址所以炸了

不过令我无语的是这个BugCheckCode依然是7e别人的BugCheckCode都是BE,就我的依旧是7e

标签:分析,BUGCHECK,00000000,Value,Key,蓝屏,nt,MyDriver10
From: https://www.cnblogs.com/murkuo/p/18199518

相关文章

  • 64-SpringBoot源码分析
    Starter是什么?我们如何使用这些Starter?为什么包扫描只会扫描核心启动类所在的包及其子包?在SpringBoot启动过程中,是如何完成自动配置的?内嵌Tomcat是如何创建并启动的?引入了web场景对应的Starter,SpringMVC是如何完成自动装配的?1.源码环境构建https://gith......
  • 基于Python的性能分析
    1、什么是性能分析字面意思就是对程序的性能,从用户角度出发就是运行的速度,占用的内存。通过对以上情况的分析,来决定程序的哪部份能被优化。提高程序的速度以及内存的使用效率。首先我们要弄清楚造成时间方面性能低的原因有哪些沉重的I/O操作,比如读取分析大文件,长时间执行数据......
  • K8S下应用异常卡顿问题的分析与学习
    K8S下应用异常卡顿问题的分析与学习背景周二自己在处理申威服务器的问题时,被同事拉进一个群聊.告知客户现场有一个特殊情况:服务晚上重启,上午速度还可以,但是到了下午就开始变的非常卡顿.因为当时正在车上也看不到具体信息.晚上九点上会进行了一次简单查看.发现......
  • AI视频智能分析技术:EasyCVR视频汇聚安防监控智能化方案
    1、视频智能分析技术原理视频智能分析技术是一项基于计算机图像视觉分析技术的创新解决方案。它利用先进的算法,将视频场景中的背景和目标进行有效分离,从而实现对目标的精准分析和追踪。该技术可以对监控摄像头拍摄到的视频进行分析和识别,从而检测和识别出视频中的各种行为。此......
  • 网络封包分析软件主要用于捕获、分析网络通信中的数据包,对于网络故障排除、安全审计、
    网络封包分析软件主要用于捕获、分析网络通信中的数据包,对于网络故障排除、安全审计、协议分析等领域至关重要。以下是几款知名的网络封包分析软件:Wireshark:Wireshark是最为流行的网络封包分析工具之一,它具有强大的数据包捕获和分析能力,支持广泛的协议,提供详细的封包解码......
  • 提升网络性能,解决故障利器——AnaTraf网络流量分析
    在当今数字化时代,网络性能对于企业的运营和发展至关重要。然而,随着网络规模的不断扩大和复杂性的增加,网络故障的排查和解决变得愈发困难。为了帮助企业提升网络性能并快速解决故障,AnaTraf推出了一款高性能的实时网络流量分析工具——AnaTraf网络流量分析仪。AnaTraf网络流量分析......
  • 网络性能监控与流量回溯分析 - 轻松诊断网络问题
    随着网络的普及和应用的不断增加,网络性能监控和故障诊断已经成为IT管理工作的重中之重。高效的网络性能监测能够及时发现和解决网络问题,确保业务的稳定运行。而对网络流量的全面分析和回溯也是网络诊断的关键所在。实时监控网络性能,定位故障根源网络性能的波动和故障可能源于......
  • 振弦采集仪在地质灾害监测中的应用案例分析
    振弦采集仪在地质灾害监测中的应用案例分析振弦采集仪(stringvibrationrecorder)是一种专门用于监测地质灾害的仪器。它通过测量地表的振动信号来分析地下发生的地质活动,例如地震、地质滑坡和岩土工程等。本文将以振弦采集仪在地质灾害监测中的应用案例为切入点,详细分析其工作原......
  • Python数据分析与挖掘实战(1-3章)
    非原创,仅个人关于《Python数据分析与挖掘实战》的学习笔记第一章基础略第二章数据分析简介基本概念元组、列表、字典、集合函数式编程:map()函数:定义一个函数,然后用map()逐一应用到map列表中的每个元素。map(lambdax+2:a)reduce()函数:用于递归计算。reduce(lambdax,......
  • 事后诸葛亮分析报告
    事后诸葛亮分析报告一、经验教训时间方面:时间的管理方面,主要是在个人上,我们团队成员仍然有些欠缺,没办法及时的完成。架构设计方面:其实刚开始确实是订好了每个人每个部分该做的事情,但是在项目开始的时候是一张白纸,框架的设计还是花费了比较长的时间,导致后来有些人比较忙,有些人......