当你电脑蓝屏时的粗暴解决方案

VSole2021-12-07 15:33:12

一、事出原因

最近不知道怎么回事,家里电脑经常性地出现蓝屏(先死机后蓝屏),很多时候有些文档没有保存便蓝屏导致文档丢失,其中也包括您现在正在看到的这一篇文章(撰写本文时,蓝了一次),以前一直比较懒,重启大法一顿怼,然后重新再做编辑,只不过PPT重做简直要人命,无奈之下,放下了所有的工作,来研究研究蓝屏的原因,顺便正儿八经使用一下Typora。

PS:本文结尾提到的解决方案较为野蛮粗暴,可能让你本就不富裕的家庭雪上加霜,请慎用!


二、准备工作

  1. 使用的工具:WinDBG
  2. 导入的文件:C:\Windows\Minidump\xxxxxx.dmp

关于WinDBG这款神器想必无需再做多的介绍,至于导入文件的目录为windows在遇到蓝屏之后会保存的dmp文件所在的位置,我的电脑是Win10系统,其它系统目前暂时不知道,在网上也有看到消息说要提前设置好,但是我并没有设置,这里也贴一下设置的图片吧。

也有文章说写入调试信息需要选择第一个。

另外需要设置WinDBG的访问符号,在WinDBG官网中可以看到

Symbol Server (Microsoft):
 复制代码 隐藏代码
srv*c:\mss*http://msdl.microsoft.com/download/symbols
Symbol Server (Citrix):
 复制代码 隐藏代码
srv*c:\css*http://ctxsym.citrix.com/symbols
.symfix c:\mss.sympath+ srv*c:\css*http://ctxsym.citrix.com/symbols

可使用环境变量设置,也可在软件File - Symbol File Path中进行设置,至此,准备工作一切就绪,下面即可进行分析。


三、分析过程

WinDBG打开dmp文件,稍等一会便可出现分析报告,我的分析报告如下:

 复制代码 隐藏代码
Microsoft (R) Windows Debugger Version 6.12.0002.633 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\Users\Tory\Desktop\120421-10187-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols;SRV*c:\mysymbol* http://msdl.microsoft.com/download/symbols
Executable search path is: 
Windows 7 Kernel Version 19041 MP (6 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0xfffff805`67c00000 PsLoadedModuleList = 0xfffff805`6882a1d0
Debug session time: Sat Dec  4 20:02:02.508 2021 (UTC + 8:00)
System Uptime: 0 days 1:07:26.549
Loading Kernel Symbols
...............................................................
................................................................
................................................................
................
Loading User Symbols
Loading unloaded module list
.........
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 3B, {c0000005, fffff80567efbfd2, ffffe90838039420, 0}
Probably caused by : Unknown_Image ( PAGE_NOT_ZERO )
Followup: MachineOwner
---------
 *** Memory manager detected 62334 instance(s) of page corruption, target is likely to have memory corruption.
5: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************
SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80567efbfd2, Address of the instruction which caused the bugcheck
Arg3: ffffe90838039420, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.
Debugging Details:
------------------
EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - 0x%p
FAULTING_IP: 
nt!RtlpIsNameInExpressionPrivate+92
fffff805`67efbfd2 6683382a        cmp     word ptr [rax],2Ah
CONTEXT:  ffffe90838039420 -- (.cxr 0xffffe90838039420)
rax=ffff7b83a1b1ab84 rbx=0000000000000074 rcx=ffffa583a1b1ab40
rdx=ffffe90838039fb0 rsi=0000000000000000 rdi=ffffa583a1b1ab40
rip=fffff80567efbfd2 rsp=ffffe90838039e20 rbp=0000000000000000
 r8=0000000000000000  r9=ffffa583a1b1ab40 r10=0000000000000032
r11=ffffe90838039fb0 r12=0000000000000000 r13=ffffbb07cac1d880
r14=0000000000000000 r15=000000000000005c
iopl=0         nv up ei pl nz na po nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00050206
nt!RtlpIsNameInExpressionPrivate+0x92:
fffff805`67efbfd2 6683382a        cmp     word ptr [rax],2Ah ds:002b:ffff7b83`a1b1ab84=????
Resetting default scope
CUSTOMER_CRASH_COUNT:  1
DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT
BUGCHECK_STR:  0x3B
PROCESS_NAME:  QQPYUserCenter
CURRENT_IRQL:  0
BAD_PAGES_DETECTED: f37e
LAST_CONTROL_TRANSFER:  from fffff80567efbe58 to fffff80567efbfd2
STACK_TEXT:  
ffffe908`38039e20 fffff805`67efbe58 : ffffbb07`00000003 00000000`00000000 ffffbb07`cac1d880 00000000`00000000 : nt!RtlpIsNameInExpressionPrivate+0x92
ffffe908`38039f10 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!RtlIsNameInExpression+0x48
SYMBOL_NAME:  PAGE_NOT_ZERO
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME:  Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP:  0
STACK_COMMAND:  .cxr 0xffffe90838039420 ; kb
BUCKET_ID:  PAGE_NOT_ZERO
Followup: MachineOwner
---------
 *** Memory manager detected 62334 instance(s) of page corruption, target is likely to have memory corruption.

重点关注第30行以下,其中BugCheck 3B, {c0000005, fffff80567efbfd2, ffffe90838039420, 0}大致可以看出错误代码为0x0000003B,百度一下即可知该错误代码多为软硬件兼容性问题,此事心里大概有一个底了。Probably caused by : Unknown_Image ( PAGE_NOT_ZERO )这里其实可以关注一下,由于结果未“Unknown_Image”所以也失去了分析它的意义了。

其实低49-54行给出了导致错误的进程具体位置,这个我看不懂,感兴趣的大佬可以给我解释一下,要怎么分析到他的具体地址。

从第81行开始较为重要,其中抛出的“VISTA_DRIVER_FAULT”表示访问驱动错误,PROCESS_NAME指向了QQPYUserCenter,表示罪魁祸首是该进程,即“QQ拼音用户中心”,但是我实在想不通为什么QQ拼音和驱动又有关系了。

继续向下看到第94、95行, 表示该进程调用了ntdll中的RtlIsNameInExpression之后又调用了RtlpIsNameInExpressionPrivate+0x92函数时出错了,该问题也可在第62-64行能够清楚看到具体出错的反汇编代码。

 复制代码 隐藏代码
FAULTING_IP: 
nt!RtlpIsNameInExpressionPrivate+92
fffff805`67efbfd2 6683382a        cmp     word ptr [rax],2Ah

四、总结

至此,分析全部结束,并做一下最终的总结:此次蓝屏主要原因是QQPYUserCenter与某个软硬件发生驱动访问时出现问题,既然有驱动则多为硬件所致。

在网上查询了很多信息,用排除法最终锁定了“Logitech MouseWare”即罗技鼠标,因为外设我就用了罗技的鼠标和键盘。


五、解决方案

更新Logitech的驱动


六、参考文献

WinDBG官网

WinDbg分析蓝屏dump原因

安装与配置windbg的symbol(符号)

WinDbg 蓝屏分析 Windows Dump 文件教程

windbg-> !analyze -v 信息详解

蓝屏windbg
本作品采用《CC 协议》,转载必须注明作者和本文链接
最近不知道怎么回事,家里电脑经常性地出现,很多时候有些文档没有保存便导致文档丢失,其中也包括您现在正在看到的这一篇文章,以前一直比较懒,重启大法一顿怼,然后重新再做编辑,只不过PPT重做简直要人命,无奈之下,放下了所有的工作。
尽管之前的漏洞也很优秀,但这个漏洞我认为是优秀者中的佼佼者。本文侧重于介绍内存构造的思路,最后给出了调试结果。后来,Siberas团队在其官网公布了此漏洞的详细细节及利用方法,它是AFD.sys驱动上的一处双重释放漏洞,通杀Wdinwos系统,影响较大。
前言死机指的是微软Windows操作系统在无法从一个系统错误中恢复过来时所显示的屏幕图像。本文只探讨由R3引起的BSoD,明眼人都知道研究R0的纯属脱裤子放屁。对于各安全厂商而言,这应该是需要特别注意的,如何连这都拦截不了,后面的防护也只是痴人说梦。
Windows SMB Ghost CVE-2020-0796漏洞分析与利用(一)
可在其中找受影响的版本复现,在受影响版本的系统中找到win32k.sys导入IDA。漏洞函数位于win32k.sys的SetImeInfoEx()函数,该函数在使用一个内核对象的字段之前并没有进行是否为空的判断,当该值为空时,函数直接读取零地址内存。如果在当前进程环境中没有映射零页面,该函数将触发页面错误异常,导致系统发生。tagWINDOWSTATIONspklList对象的结构为:漏洞触发验证查看SSDT表dd KeServiceDescriptorTabledds Address L11C 显示地址里面值指向的地址. 以4个字节显示。
IDA故障参考
2023-07-10 10:08:00
IDA故障排除过程记录由于IDA闭源,又加上其十分无效的官方文档。因此如果出现任何错误,都需要进行分析和查错,这一过程很麻烦。按下确定之后,IDA就随风而逝了。你气急败坏的不断导入文件,但是IDA就是屹然不动。观察故障的表和log,也没有任何反馈。简称,用IDA调试IDA。首先你要禁用所有plugin。使用WinDBG打开导出的dump文件:windbg大名鼎鼎,其威名必不用说。
返回到内核继续执行的时候,会将用户层函数中指定的地址保存到窗口对象偏移0x128的pExtraBytes成员中。通过劫持用户层函数的执行,可以让SetWindowLongPtr函数对不合法地址进行写入会产生BSOD,也可以通过计算来扩大其他窗口的cbwndExtra,从而实现任意地址读写,最终实现提权
在所有函数调用发生时,向栈帧内压入一个额外的随机 DWORD,随机数标注为“SecurityCookie”。在函数返回之前,系统将执行一个额外的安全验证操作,被称做 Security check。
API(Application Programming Interface),我们调用时只需提供正确的参数以及接收返回值就可以判断API执行是否成功或者通过GetLastError获得错误原因.
然而,需要注意HTA攻击被阻止,是因为阻止了所有HTA文件的策略。EXE和DLL攻击都成功执行,没有发现,也没有产生任何遥测。在McAfee工程师协助下,策略配置成最佳安全。在HTA攻击中,检测到低报警,但没有阻止。
VSole
网络安全专家