三次蓝屏对内核崩溃日志的分析记录

下面的所有内容都是WinDBG的输出内容

//后跟的所有内容都是针对下一行具体项的具体解释

Microsoft ® Windows Debugger Version 6.12.0002.633 AMD64
Copyright © Microsoft Corporation. All rights reserved.

Loading Dump File [C:\Windows\Minidump\103021-8359-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: SRVC:\Symbolshttp://msdl.microsoft.com/download/symbols
Executable search path is:
// 内核的版本:可以看到Win10用的还是win7的内核只是进行了修改
Windows 7 Kernel Version 19041 MP (24 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 19041.1.amd64fre.vb_release.191206-1406
Machine Name:
Kernel base = 0xfffff80526800000 PsLoadedModuleList = 0xfffff8052742a3d0
Debug session time: Sat Oct 30 21:32:19.861 2021 (UTC + 8:00)
// 这一行就比较重要了: 系统的运行时间,可以看到我运行了差不多2h,OS蓝屏挂掉了
System Uptime: 0 days 1:56:51.634
Loading Kernel Symbols




Loading User Symbols
Loading unloaded module list

// 接下来的内容就是比较重要的信息内容,记载的是这次OS挂掉的系统错误检查分析


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

Use !analyze -v to get detailed debugging information.

BugCheck D1, {0, 2, 1, fffff8053b56f00c}
// !!! 注意:第一个十分明显的错误警告出现了,无法加载NV的一个镜像 —> 错误产生条件+1 < NV镜像出错 >
// 解决方案:
// https://validedge.com/nvlddmkm-sys/#:~:text=How%20to%20Fix%20nvlddmkm.Sys%20Error%20on%20Windows%2010,…%206%20Method%20%236%20Update%20Your%20Windows.%20
// 这个网页上阐述了产生NV这个驱动文件缺失的六个解决方案
// C:\Windows\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_1c83a5d7cffd7bff
// NV这个模块来自上面的这个路径,尝试卸载驱动重新装一个
Unable to load image \SystemRoot\System32\DriverStore\FileRepository\nv_dispi.inf_amd64_44dc4eefedc0d082\nvlddmkm.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for nvlddmkm.sys
*** ERROR: Module load completed but symbols could not be loaded for nvlddmkm.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** ERROR: Module load completed but symbols could not be loaded for win32k.sys
// 可能产生的错误的原因:内存损坏
Probably caused by : memory_corruption
Followup: memory_corruption

下面是具体的调试信息
DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high. This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 0000000000000000, memory referenced
Arg2: 0000000000000002, IRQL
Arg3: 0000000000000001, value 0 = read operation, 1 = write operation
Arg4: fffff8053b56f00c, address which referenced memory
// 这里接下来是调试的详情信息
Debugging Details:
------------------

WRITE_ADDRESS: unable to get nt!MmSpecialPoolStart
unable to get nt!MmSpecialPoolEnd
unable to get nt!MmPoolCodeStart
unable to get nt!MmPoolCodeEnd
0000000000000000

CURRENT_IRQL: 2

FAULTING_IP:
// 看到这个mov我又想起了我那段学汇编的痛苦岁月 T_T
// NV模块(nvlddmkm)的名字在这里又出现了一次。NV+1
// 有一个很重要的问题,如果每次处理了之后依旧出现蓝屏的问题,注意留意一下这个驱动模块的每次偏移的地址是否一致
nvlddmkm+81f00c
fffff805`3b56f00c 458c03 mov word ptr [r11],es

CUSTOMER_CRASH_COUNT: 1
// 大概的意思就是这一块内存中出现了代码的损坏
DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xD1
// 触发蓝屏的进程:系统
PROCESS_NAME: System
// 最后一次控制的转换地址
LAST_CONTROL_TRANSFER: from fffff80526c07d69 to fffff80526bf5e40
// 堆栈表
STACK_TEXT:
ffff8085332e57f8 fffff80526c07d69 : 000000000000000a 0000000000000000 0000000000000002 0000000000000001 : nt!KeBugCheckEx
ffff8085332e5800 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KiBugCheckDispatch+0x69

STACK_COMMAND: .bugcheck ; kb
// 这个!chkimg的调试命令是检查符号表与其他地方的符号表的差异来检查镜像中存在的错误
CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff80526b9752f-fffff80526b97531 3 bytes - nt!MiFreeUltraMapping+33
[ 7d fb f6:6b d7 ae ]
fffff80526bf7198-fffff80526bf7199 2 bytes - nt!KiChainedDispatch+b8 (+0x5fc69)
[ 48 ff:4c 8b ]
fffff80526bf719f-fffff80526bf71a2 4 bytes - nt!KiChainedDispatch+bf (+0x07)
[ 0f 1f 44 00:e8 7c d2 61 ]
9 errors : !nt (fffff80526b9752f-fffff80526bf71a2)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

Followup: memory_corruption



第二份内核日志文件分析

!analyze -v
*******************************************************************************
* Bugcheck Analysis *
*******************************************************************************

DPC_WATCHDOG_VIOLATION (133)
The DPC watchdog detected a prolonged run time at an IRQL of DISPATCH_LEVEL
or above.
Arguments:
Arg1: 0000000000000001, The system cumulatively spent an extended period of time at
DISPATCH_LEVEL or above. The offending component can usually be
identified with a stack trace.
Arg2: 0000000000001e00, The watchdog period.
Arg3: fffff8051c8fb320
Arg4: 0000000000000000

Debugging Details:

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0x133
// 导致蓝屏的程序:文件夹(对!我在打开文件夹的时候卡死了蓝屏了)
PROCESS_NAME: explorer.exe

CURRENT_IRQL: d

LAST_CONTROL_TRANSFER: from fffff8051c03ae42 to fffff8051bff5e40

STACK_TEXT:
ffffcc0169ad3e18 fffff8051c03ae42 : 0000000000000133 0000000000000001 0000000000001e00 fffff8051c8fb320 : nt!KeBugCheckEx
ffffcc0169ad3e20 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!KeAccumulateTicks+0x1c8c42

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !win32k
ffffcb5ba3ea4c6c-ffffcb5ba3ea4c71 6 bytes - win32k!NtUserCallHwndLock+10
[ ff 15 ee fc 06 00:e8 2f 56 09 00 90 ]
ffffcb5ba3ea4c90-ffffcb5ba3ea4c95 6 bytes - win32k!NtUserCallHwndLockSafe+10 (+0x24)
[ ff 15 ca fc 06 00:e8 0b 56 09 00 90 ]
ffffcb5ba3ea4cb4-ffffcb5ba3ea4cb9 6 bytes - win32k!NtUserCallHwndOpt+10 (+0x24)
[ ff 15 a6 fc 06 00:e8 e7 55 09 00 90 ]
ffffcb5ba3ea4cd8-ffffcb5ba3ea4cdd 6 bytes - win32k!NtUserCallHwndParam+10 (+0x24)
[ ff 15 82 fc 06 00:e8 c3 55 09 00 90 ]
ffffcb5ba3ea4cfc-ffffcb5ba3ea4d01 6 bytes - win32k!NtUserCallHwndParamLock+10 (+0x24)
[ ff 15 5e fc 06 00:e8 9f 55 09 00 90 ]
ffffcb5ba3ea4d20-ffffcb5ba3ea4d25 6 bytes - win32k!NtUserCallHwndParamLockSafe+10 (+0x24)
[ ff 15 3a fc 06 00:e8 7b 55 09 00 90 ]
ffffcb5ba3ea4d44-ffffcb5ba3ea4d49 6 bytes - win32k!NtUserCallHwndSafe+10 (+0x24)
[ ff 15 16 fc 06 00:e8 57 55 09 00 90 ]
ffffcb5ba3ea4d68-ffffcb5ba3ea4d6d 6 bytes - win32k!NtUserCallMsgFilter+10 (+0x24)
[ ff 15 f2 fb 06 00:e8 33 55 09 00 90 ]
48 errors : !win32k (ffffcb5ba3ea4c6c-ffffcb5ba3ea4d6d)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

====================================================================================
第三份日志
!analyze -v


  •                                                                         *
    
  •                    Bugcheck Analysis                                    *
    
  •                                                                         *
    

CRITICAL_PROCESS_DIED (ef)
A critical system process died
Arguments:
Arg1: ffffa20db825d240, Process object
Arg2: 0000000000000000
Arg3: 0000000000000000
Arg4: 0000000000000000

Debugging Details:

PROCESS_OBJECT: ffffa20db825d240

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: CODE_CORRUPTION

BUGCHECK_STR: 0xEF

PROCESS_NAME: svchost.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff8035b706972 to fffff8035b1f5e40

STACK_TEXT:
fffffd8721214938 fffff8035b706972 : 00000000000000ef ffffa20db825d240 0000000000000000 0000000000000000 : nt!KeBugCheckEx
fffffd8721214940 0000000000000000 : 0000000000000000 0000000000000000 0000000000000000 0000000000000000 : nt!PspCatchCriticalBreak+0x10e

STACK_COMMAND: kb

CHKIMG_EXTENSION: !chkimg -lo 50 -d !nt
fffff8035b19752e-fffff8035b197531 4 bytes - nt!MiFreeUltraMapping+32
[ a0 7d fb f6:20 63 c6 8c ]
4 errors : !nt (fffff8035b19752e-fffff8035b197531)

MODULE_NAME: memory_corruption

IMAGE_NAME: memory_corruption

FOLLOWUP_NAME: memory_corruption

DEBUG_FLR_IMAGE_TIMESTAMP: 0

MEMORY_CORRUPTOR: LARGE

FAILURE_BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

BUCKET_ID: X64_MEMORY_CORRUPTION_LARGE

Followup: memory_corruption

总结:经过上面一大堆乱七八糟的崩溃日志的分析,其实每一次的蓝屏原因都是不尽相同的,第一次是因为NV的驱动模块导致了系统的进程崩溃,第二次是win32的模块,第三次是也是因为win32的模块,因为我的系统是新重装的,初步定位蓝屏的原因为内存损坏(指定是超频超过劲了 T T !

内存返厂保修中。。。。。。。

  • 3
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 3
    评论
蓝屏是指计算机在运行过程中发生了严重错误导致操作系统无法继续正常工作,屏幕显示一片蓝色,并在某些情况下自动重启。蓝屏常见问题有很多种原因,如硬件故障、驱动程序冲突、不稳定的系统内核等。 而dump文件是指计算机发生蓝屏时所生成的一个记录文件,它包含着计算机的内存快照,可以用来分析蓝屏原因。下面我们来介绍一下蓝屏dump文件分析的一般步骤: 1. 首先,我们需要查找dump文件的位置。通常情况下,dump文件会被保存在操作系统安装盘的Windows文件夹下的Minidump文件夹中。 2. 找到dump文件后,我们可以使用一些工具来分析它。其中最常用的是Windows自带的调试工具WinDbg,它可以加载dump文件并提供详细的分析报告。 3. 打开WinDbg后,我们需要加载dump文件。点击菜单中的"File",选择"Open Crash Dump",并选择要分析的dump文件。 4. 分析dump文件时,我们可以查看错误信息、堆栈跟踪等关键信息,以确定故障的原因。具体分析过程比较复杂,需要针对不同的蓝屏问题进行相应的分析方法。 5. 在分析过程中,我们还可以使用WinDbg提供的命令和工具来获取更详细的信息,比如查看线程信息、内存状态等。 6. 分析完成后,我们可以根据分析结果采取相应的措施来解决问题。比如更新驱动程序、修复操作系统、更换故障的硬件等。 总而言之,通过蓝屏dump文件的分析,我们可以定位并解决计算机蓝屏问题的原因。这需要一定的专业知识和经验,同时也需要耐心和细心进行分析。希望以上介绍对您有所帮助。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值