精华内容
下载资源
问答
  • 查找/分析Windows蓝屏DMP文件

    万次阅读 2019-10-16 20:04:10
    当电脑出现蓝屏时,Windows系统会自动生成一个蓝屏错误DMP文件,这个文件保存在系统哪个位置,哪个目录下面,怎么获取到这个蓝屏错误DMP文件呢?若没有经过人为更改,蓝屏错误DMP文件一般默认会保存在系统根目录下,...

    引言

    蓝屏错误DMP文件一般默认会保存在系统根目录下,如C:\Windows\或C:\Windows\Minidump文件夹下,这是因为Windows系统版本不同而不同。
    需要使用到微软的Debugging Tools来打开蓝屏错误DMP文件,结合官网和经验来判断蓝屏发生的原因。

    一、查找DMP文件所在位置

    1. 在Windows10系统中,“我的电脑“–“”属性“”进入"系统信息(system info)"

      也可以按Windows键+X,选择“系统(system)”–“系统信息(system info)”

      在这里插入图片描述在这里插入图片描述

    2. 然后点击“更改设置(Change Setting)”–“高级(Advanced)”–“设置Settings…”,查看Dump File所在目录

      也可以在“运行”窗口输入“sysdm.cpl”直接进入“系统属性(System Properties)”

      在这里插入图片描述3. 如上图,DMP文件所在目录是%SystemRoot%
      %SystemRoot%是系统中的一个变量,是指操作系统的系统目录或者是根目录,我的系统安装在C盘,所以%SystemRoot%对应的目录是C:\Windows。

      请注意!
      DMP文件还可以存放在%SystemRoot%\Minidump中

      minidump文件夹下的文件可能会处于权限保护之下,建议首先复制文件到桌面
      在这里插入图片描述

    二、安装分析工具Windbg

    1. 分析DMP文件我们一般使用Windbg这个工具,而该工具包含中SDK里,SDK的下载地址:
      蓝屏Dump分析工具 x86位版本下载:微软Windbg官方安装版x86(单独安装使用)
      蓝屏Dump分析工具 x64位版本下载:微软Windbg官方安装版x64(单独安装使用)
      如果有需要可以下载完整版SDK:Windows 10 SDK下载链接(部分安装使用)
      在这里插入图片描述
    2. 安装完成后重启电脑,即可打开Windbg工具。

    三、分析DMP文件

    1. 设置符号表

      注:符号表是WinDbg关键的“数据库”,里边储存着各种蓝屏代码的分析结果。

      1.1 运行Windbg,然后按Ctrl+S或从文件菜单中打开符号表设置窗;
      1.2 将符号表地址:SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols 粘贴在输入框中,确定。

      注:加粗字体(C:\Symbols)为符号表本地存储路径,建议固定路径,你也可以选择其它路径,可避免符号表重复下载。

      在这里插入图片描述

    2. 打开DMP文件或将DMP拖进Windbg
      在这里插入图片描述在这里插入图片描述
      如果在打开第二个DMP文件时,可能因为上一个分析记录未清除,导致无法直接分析下一个dmp文件,可以使用快捷键Shift+F5来关闭上一个DMP的分析记录。

    3. 打开之后首先查看两点#

      • 第一个关键信息:Probably caused by:*********
      • 第二个关键信息:找到并点击“!analyze –v ”,从弹出的内容中查找 BUGCHECK_STR: ********

      参考链接:https://blog.csdn.net/qq_35583007/article/details/92793605#commentBox

    4. 根据以上信息,再对照蓝屏常见错误:Windows常见蓝屏故障分析(MVP 撰稿) 中的信息,找到问题对应的大致可能的原因。

    展开全文
  • 我们以收集一款收费软件引起windows系统蓝屏为例子,进行讲解。 常规报错需收集日志信息:1、计费服务端日志:服务端安装目录下手动创建wxlog和wxpluglog两个文件夹,分别获取计费日志及插件日志。若网吧之前已经...

    原文效果更好

    http://blog.csdn.net/cd520yy/article/details/12776811

     我们以收集一款收费软件引起windows系统蓝屏为例子,进行讲解。

        

    常规报错需收集日志信息:

    1、计费服务端日志:服务端安装目录下手动创建wxlog和wxpluglog两个文件夹,分别获取计费日志及插件日志。若网吧之前已经存在日志目录并且日志较大,可以先删除之前的日志文件,重现问题后再提取新日志

    2、计费客户端日志:在客户端system32目录下手动创建wxlog和wxpluglog两个文件夹,分别获取计费日志及插件日志。

    蓝屏问题需要提取dump文件:

    有盘环境

    一、设置日志文件

    方法一:(推荐:获取的日志信息全面,更利于分析)

    右键“我的电脑”,选择“属性”,在“高级=>启动和故障恢复”里选择“设置”,参照下图所示进行设置

    方法二:(不推荐:日志信息简短,只能进行粗略的分析)

    右键“我的电脑”,选择“属性”,在“高级=>启动和故障恢复”里选择“设置”,参照下图所示进行设置

    二、获取日志文件

    日志文件存放在以下目录:
      核心内存转储路径:C:\WINDOWS\MEMORY.DMP
      小内存转储文件路径:C:\WINDOWS\Minidump\

    请在以上路径获取日志文件,也可自定义日志文件存放路径(最好放在非还原保护的盘符下,这样可以避免系统重启导致的日志丢失现象。

    =====================

    无盘环境(有盘环境同样适用)

    一、设置日志文件

    利用系统自带的程序drwtsn32.exe(目录:C:\WINDOWS\system32\)进行故障日志和dump的获取,具体操作如下:

    1、在系统“运行”里输入:drwtsn32.exe,弹出如下图所示窗口进行设置:

    注:在①处设置日志和故障dmp输出地址(最好放在非还原保护的盘符下,这样可避免系统重启导致的日志丢失现象),并按照②所示对选项进行设置。

    2、执行完上一步操作后,在系统“运行”中输入:drwtsn32 -i进行安装,弹出以下窗口即表示安装成功。

    二、获取日志文件

    在出现故障的时候,请取得问题网吧机器上设置文件夹中的log日志和dmp文件。

    =====================

    DMP文件提取所需注意点:

    1、 虚拟内存设置
      虚拟内存(页面文件)必须设置在C盘,初始大小应大于物理内存至少1M。不然无法打到完全内存转储。

    2:转储文件默认路径为
      %SystemRoot%\MEMORY.DMP。默认在WINDOWS目录下。可以设置到其他路径。

    3:部分非常见系统崩溃的蓝屏现象无法提取DMP

    4:4G或者更大的内存需要创建完整DMP文件,必须对boot.ini使用/MAXMEM转换。

    =====================

    DMP文件提取常见问题

    问:还原状态下DMP文件是否会被还原
      答:建议用户将DMP文件放到不会还原的目录或盘符,无盘用户可考虑使用U盘,或移动硬盘。


    问:开机就蓝的如何提取
      答:可以直接在设置路径的时候,设置U盘的盘符,然后待日志生成后,在系统启动后的U盘去查找。

    而后重启PC、再次重现问题、持续按下右侧Ctrl 按钮并双按键盘上的Scroll 按钮、等待直到DMP文件创建完成并在正常模式下重启系统、确保完整的DMP文件已经被成功创建、重启PC。



    展开全文
  • windows蓝屏dump分析方法

    千次阅读 2018-08-13 17:29:31
    它能够通过dmp文件轻松的定位到问题根源,可用于分析蓝屏、程序崩溃(IE崩溃)原因,是我们日常工作中必不可少的一个有力工具,学会使用它,将有效提升我们的问题解决效率和准确率。 二、WinDbg6.12.0002.633下载:...

    一、WinDbg是什么?它能做什么?

      WinDbg是在windows平台下,强大的用户态和内核态调试工具。它能够通过dmp文件轻松的定位到问题根源,可用于分析蓝屏、程序崩溃(IE崩溃)原因,是我们日常工作中必不可少的一个有力工具,学会使用它,将有效提升我们的问题解决效率和准确率。

    二、WinDbg6.12.0002.633下载:

    x86位版本下载:【微软官方安装版

    蓝屏Dump分析工具WinDbg(x86).rar    35,110 次

    x64位版本下载:【微软官方安装版

    蓝屏Dump分析工具WinDbg(x64).rar    40,150 次

    三、设置符号表:

      符号表是WinDbg关键的“数据库”,如果没有它,WinDbg基本上就是个废物,无法分析出更多问题原因。所以使用WinDbg设置符号表,是必须要走的一步。
    1、运行WinDbg软件,然后按【Ctrl+S】弹出符号表设置窗
    2、将符号表地址:SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols粘贴在输入框中,点击确定即可。
    注:红色字体为符号表本地存储路径,建议固定路径,可避免符号表重复下载。

    1

    四、学会打开第一个dmp文件!

    2

      当你拿到一个dmp文件后,可使用【Ctrl+D】快捷键来打开一个dmp文件,或者点击WinDbg界面上的【File=>Open Crash Dump...】按钮,来打开一个dmp文件。第一次打开dmp文件时,可能会收到如下提示,出现这个提示时,勾选“Don't ask again in this WinDbg session”,然后点否即可。


      当你想打开第二个dmp文件时,可能因为上一个分析记录未清除,导致无法直接分析下一个dmp文件,此时你可以使用快捷键【Shift+F5】来关闭上一个dmp分析记录。

      至此,简单的WinDbg使用你已经学会了!

    五、通过简单的几个步骤学会分析一些dmp文件。

    分享一个8E蓝屏dmp案例的分析过程:
      当你打开一个dmp文件后,可能因为太多信息,让你无所适从,不过没关系,我们只需要关注几个关键信息即可。

    第一个关键信息:System Uptime(开机时间):

      通过观察这个时间你就可以知道问题是在什么时候出现的,例如时间小于1分钟基本可以定位为开机蓝屏,反之大于一分钟则可证明是上机后或玩的过程中出现问题了。

    接下来用一个简单的例子来学习简单的dmp分析,下图中System Uptime: 0 days 0:14:23.581,意思是0天(days)0小时14分23秒581毫秒时出现蓝屏了,看来是上机没多久就蓝屏了,这位顾客很悲催……

    3

      那么是什么导致蓝屏的呢?接下来我们就要注意第二个关键信息了!

    第二个关键信息:Probaly caused by(造成蓝屏可能的原因)

      这个信息是相对比较重要的一个信息,如果你运气好的话,通过这个信息基本上可以看到导致蓝屏的驱动或者程序名称了,就像下图一样,初步的分析已经有了结果,Probaly caused by后面显示的是一个名为KiMsgProtect.sys的驱动文件导致蓝屏,这个文件就是恒信一卡通的一个关键驱动。因此蓝屏则很有可能和一卡通有关。

    括号中驱动文件名后面的+号代表的是偏移地址,假如多个dmp文件的驱动文件名一样,且偏移地址也一样,则问题原因极有可能是同一个,这个偏移地址与汇编有关,这里不多做介绍。

    4

      其实,对于分析蓝屏dmp并不是每次运气都那么好,假如刚刚打开dmp文件未看到明确的蓝屏原因时,我们就需要借助一个命令来进一步分析dmp,这个命令就是:!analyze -v,这个命令能够自动分析绝大部分蓝屏原因。当初步分析没有结果时,可以使用该命令进一步分析故障原因,当然你也可以直接点击链接样式的!analyze -v来进行执行该命令,为了让大家更直观的看懂里面的信息,大家可以直接看图片中的注释信息。

    5

    6

      看了这么多信息之后,这个蓝屏dmp到底是怎么回事呢?根据dmp给出的信息,应该是:顾客上机0天(days)0小时14分23秒581毫秒时,一个名为PinyinUp.exe触发了KiMsgProtect.sys这个驱动的一个Bug,导致蓝屏。 

      那么PinyinUp.exe和KiMsgProtect.sys都是哪个厂商的?一般要知道这个信息,只能去用户的机器上找了,我去找了之后发现PinyinUp.exe是搜狗输入法的自动升级程序,KiMsgProtect.sys是恒信一卡通这个计费软件的驱动,所以这个dmp表示出来的意思看上去是搜狗拼音和恒信一卡通搞在一起,出了问题!当然排除方法很简单,把搜狗输入法的自动升级程序删除掉,再看看是否仍然有蓝屏问题发生就ok了!

      学到这里,基本上已经可以分析绝大部分dmp文件了,但是分析蓝屏dmp要比较谨慎,对信息需要重新验证一次才更加保险,验证方法很简单,在WinDbg的命令输入框内,输入!process命令,就可以验证触发蓝屏的程序到底是否正确了。

    7

     

    运行!process命令后得到的信息:

    8

      至此,掌握以上几个简单的分析方法之后,基本上绝大多数dmp大家都可以独立分析了,当然WinDbg是个强大的工具,同时蓝屏的原因也有很多,如果想分析的足够准确,那么就只有多学多练,多去分析,因为WinDbg分析除了懂得几个命令之外,经验更加重要!

    合理再给大家一些分析建议:

      并不一定每个dmp文件都可以分析出有用的结论,因此分析dmp并不需要对每个dmp文件的结果过分纠结,其实蓝屏dmp分析也是观察一个规律或者规模的问题定位方法而已。例如你分析了10个dmp,有5个dmp都指向同一个蓝屏原因,另外5个dmp的信息五花八门时,那么你完全可以先处理掉5次蓝屏,同一个原因的问题,因为解决了这个问题之后,后面的问题可能就都解决了!

      vDiskBus+da6c这个蓝屏信息是指网维大师蓝屏硬盘的dmp捕捉机制,这并不是蓝屏原因,有很多朋友因为文章看到一半就去折腾,结果得出一些错误结论,所以这里特意提醒下大家,看到vDiskBus+da6c这个信息之后,就不要再判断错误了,这个信息可以证实的信息是:这个dmp文件是通过网维大师蓝屏鹰眼捕捉到的,且是在网维无盘客户机上捕捉到的,其它的就不能代表什么了。

     

    声明: 本文由(死性不改)原创编译,转载请保留链接: http://support.icafe8.com/technologynews/focus/932.html

    展开全文
  • 工具是dbg,主要用于调试程序,x64_dbg采用 QT 平台编写,操作简单,很容易上手,这块可以应用于windows系统中的dbg格式文件的查看,还有蓝屏文件的具体信息获取,都是很好用的
  • windows 蓝屏 DMP文件分析

    千次阅读 2012-08-02 13:06:25
    蓝屏瞬间,系统会形成一个存储器转储文件——死机瞬间的内存映像,通常是C:WINDOWSMinidmp 目录下的DMP文件,它就是我们要找的救星,分析它就能查找到问题所在。 “救星”帮忙,看清 DMP文件需要使用MS提供的...
     

     

    windbg 更详细请看http://support.icafe8.com/technologynews/focus/932.html

     

    在蓝屏瞬间,系统会形成一个存储器转储文件——死机瞬间的内存映像,通常是C:WINDOWSMinidmp 目录下的DMP文件,它就是我们要找的救星,分析它就能查找到问题所在。
    “救星”帮忙,看清
    DMP文件需要使用MS提供的WinDbg工具来分析:第一步:设置符号文件路径,点击”Files→Symbol File Path“,输入”SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols“(微软提供的一个网络上的symbol服务器)。
    第二步:打开minidump文件进行分析,点击”File→Open Crash Dump“,如打开C:WINDOWSMinidumpMini08100701.dmp。根据前面设置的符号文件地址,软件会自动连接到微软网站,得到符号信息。
    当下面的命令行运行出现!analyze-v(常用的一个分析命令)蓝色命令时,点击它就将得到DMP文件详细的信息。从中找到蓝色字母部分就是什么软件引起的蓝屏了。【以上来自《电脑爱好者》24期】
    下面是一段例子:

    Dump文件的分析
        当按上面的方法运行后,windbg输出了以下内容:
    *** Fatal System Error: 0x000000d1
                           (0xE1147008,0x0000001C,0x00000000,0xFBE93403)

      Break instruction exception - code 80000003 (first chance)

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

      A fatal system error has occurred.

    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    2.BugCheck D1, {e1147008, 1c, 0, fbe93403}

    *** ERROR: Module load completed but symbols could not be loaded for myfault.sys
    3.Probably caused by : myfault.sys ( myfault+403 )

    Followup: MachineOwner
    ---------
    nt!RtlpBreakWithStatusInstruction:
    80527da8 cc              int     3
    Kd:> 

    上面这一段,有用的信息,如1和2两段,说明的是一个问题,都指明了BugCheck是D1,并给了四个参数,这里的D1可以在windbg
    文档的Bug Check Code Reference中查出其具体含义,也可用!analyze –show D1命令查出。3说明引起的原因是myfault.sys
    模块。接着在kd后输入!analyze –v命令,这个命令是详细列出dump文件的信息。

    windbg输出如下:
    kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)  //指明Bugcheck 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: e1147008, memory referenced
    Arg2: 0000001c, IRQL
    Arg3: 00000000, value 0 = read operation, 1 = write operation
    Arg4: fbe93403, address which referenced memory
                     //给出了相应的四个参数,第二列是代号,第三列是解释
    Debugging Details:
    ------------------
    READ_ADDRESS:  e1147008 Paged pool       //上面的Arg1.

    CURRENT_IRQL:  1c       //上面的Arg2

    FAULTING_IP:     //指出发生错误时所执行的指令
    myfault+403
    fbe93403 8b06            mov     eax,dword ptr [esi]

    DEFAULT_BUCKET_ID:  DRIVER_FAULT   //指出错误类型,是驱动错误

    BUGCHECK_STR:  0xD1   //bugcheck索引,可查windbg文档,也可!analyze –show D1

    PROCESS_NAME:  NotMyfault.exe  //错误所属进程

    TRAP_FRAME:  f9357b80 --(trap fffffffff9357b80)//错误时各寄存器的内容
    ErrCode = 00000000
    eax=00000000 ebx=8111f330 ecx=000000d1 edx=0000001c esi=e1147008 edi=00000000
    eip=fbe93403 esp=f9357bf4 ebp=f9357c58 iopl=0         nv up ei pl zr na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
    myfault+0x403:
    fbe93403 8b06            mov     eax,dword ptr [esi]  ds:0023:e1147008=????????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from 804f880d to 80527da8

    STACK_TEXT: //反映了错误前堆栈中函数调用情况,最下面的0x7c801671处函数调用ntdll中的ZwDeviceIoControlFile,接着
    调用了ntdll中的KiFastSystemCallRet,再接着调用了nt(这里的nt指Ntoskrnl)中的KiFastCallEntry,一直到myfault+0x403,
    发生异常。
    f9357734 804f880d 00000003 f9357a90 00000000 nt!RtlpBreakWithStatusInstruction
    f9357780 804f93fa 00000003 e1147008 fbe93403 nt!KiBugCheckDebugBreak+0x19
    f9357b60 80540853 0000000a e1147008 0000001c nt!KeBugCheck2+0x574
    f9357b60 fbe93403 0000000a e1147008 0000001c nt!KiTrap0E+0x233
    WARNING: Stack unwind information not available. Following frames may be wrong.
    f9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault+0x403
    f9357d00 8056e33c 00000090 00000000 00000000 nt!IopXxxControlFile+0x5e7
    f9357d34 8053d808 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
    f9357d34 7c92eb94 00000090 00000000 00000000 nt!KiFastCallEntry+0xf8
    0012f9f0 7c92d8ef 7c801671 00000090 00000000 ntdll!KiFastSystemCallRet
    0012f9f4 7c801671 00000090 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
    0012fa54 004018c2 00000090 83360018 00000000 0x7c801671


    STACK_COMMAND:  kb

    FOLLOWUP_IP: //反汇编了发生错误指令的代码
    myfault+403
    fbe93403 8b06            mov     eax,dword ptr [esi]

    SYMBOL_STACK_INDEX:  4
    FOLLOWUP_NAME:  MachineOwner
    MODULE_NAME: myfault
    IMAGE_NAME:  myfault.sys
    DEBUG_FLR_IMAGE_TIMESTAMP:  43774e1d
    SYMBOL_NAME:  myfault+403
    FAILURE_BUCKET_ID:  0xD1_myfault+403
    BUCKET_ID:  0xD1_myfault+403
    Followup: MachineOwner
    //以上几段看名字就知道了,是以上信息的重复没有多大价值。
    四。总结
        通过以上的分析,知道了蓝屏的原因是Bugcheck D1引起的,是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发
    蓝屏的驱动程序是myfault.sys,属于notmyfaulf.exe的进程。还知道了蓝屏前bug程序myfault.sys的调用情况等多个有用信息,
    接着就可以在myfault.sys源程序中进行bug修改了。

    windows 蓝屏 DMP文件分析
    2011年03月29日 星期二 下午 07:41

    在蓝屏瞬间,系统会形成一个存储器转储文件——死机瞬间的内存映像,通常是C:WINDOWSMinidmp 目录下的DMP文件,它就是我们要找的救星,分析它就能查找到问题所在。
    “救星”帮忙,看清
    DMP文件需要使用MS提供的WinDbg工具来分析:第一步:设置符号文件路径,点击”Files→Symbol File Path“,输入”SRV*DownstreamStore*http://msdl.microsoft.com/download/symbols“(微软提供的一个网络上的symbol服务器)。
    第二步:打开minidump文件进行分析,点击”File→Open Crash Dump“,如打开C:WINDOWSMinidumpMini08100701.dmp。根据前面设置的符号文件地址,软件会自动连接到微软网站,得到符号信息。
    当下面的命令行运行出现!analyze-v(常用的一个分析命令)蓝色命令时,点击它就将得到DMP文件详细的信息。从中找到蓝色字母部分就是什么软件引起的蓝屏了。【以上来自《电脑爱好者》24期】
    下面是一段例子:

    Dump文件的分析
        当按上面的方法运行后,windbg输出了以下内容:
    *** Fatal System Error: 0x000000d1
                           (0xE1147008,0x0000001C,0x00000000,0xFBE93403)

      Break instruction exception - code 80000003 (first chance)

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

      A fatal system error has occurred.

    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    2.BugCheck D1, {e1147008, 1c, 0, fbe93403}

    *** ERROR: Module load completed but symbols could not be loaded for myfault.sys
    3.Probably caused by : myfault.sys ( myfault+403 )

    Followup: MachineOwner
    ---------
    nt!RtlpBreakWithStatusInstruction:
    80527da8 cc              int     3
    Kd:> 

    上面这一段,有用的信息,如1和2两段,说明的是一个问题,都指明了BugCheck是D1,并给了四个参数,这里的D1可以在windbg
    文档的Bug Check Code Reference中查出其具体含义,也可用!analyze –show D1命令查出。3说明引起的原因是myfault.sys
    模块。接着在kd后输入!analyze –v命令,这个命令是详细列出dump文件的信息。

    windbg输出如下:
    kd> !analyze -v
    *******************************************************************************
    *                                                                             *
    *                        Bugcheck Analysis                                    *
    *                                                                             *
    *******************************************************************************

    DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)  //指明Bugcheck 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: e1147008, memory referenced
    Arg2: 0000001c, IRQL
    Arg3: 00000000, value 0 = read operation, 1 = write operation
    Arg4: fbe93403, address which referenced memory
                     //给出了相应的四个参数,第二列是代号,第三列是解释
    Debugging Details:
    ------------------
    READ_ADDRESS:  e1147008 Paged pool       //上面的Arg1.

    CURRENT_IRQL:  1c       //上面的Arg2

    FAULTING_IP:     //指出发生错误时所执行的指令
    myfault+403
    fbe93403 8b06            mov     eax,dword ptr [esi]

    DEFAULT_BUCKET_ID:  DRIVER_FAULT   //指出错误类型,是驱动错误

    BUGCHECK_STR:  0xD1   //bugcheck索引,可查windbg文档,也可!analyze –show D1

    PROCESS_NAME:  NotMyfault.exe  //错误所属进程

    TRAP_FRAME:  f9357b80 --(trap fffffffff9357b80)//错误时各寄存器的内容
    ErrCode = 00000000
    eax=00000000 ebx=8111f330 ecx=000000d1 edx=0000001c esi=e1147008 edi=00000000
    eip=fbe93403 esp=f9357bf4 ebp=f9357c58 iopl=0         nv up ei pl zr na pe nc
    cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010246
    myfault+0x403:
    fbe93403 8b06            mov     eax,dword ptr [esi]  ds:0023:e1147008=????????
    Resetting default scope

    LAST_CONTROL_TRANSFER:  from 804f880d to 80527da8

    STACK_TEXT: //反映了错误前堆栈中函数调用情况,最下面的0x7c801671处函数调用ntdll中的ZwDeviceIoControlFile,接着
    调用了ntdll中的KiFastSystemCallRet,再接着调用了nt(这里的nt指Ntoskrnl)中的KiFastCallEntry,一直到myfault+0x403,
    发生异常。
    f9357734 804f880d 00000003 f9357a90 00000000 nt!RtlpBreakWithStatusInstruction
    f9357780 804f93fa 00000003 e1147008 fbe93403 nt!KiBugCheckDebugBreak+0x19
    f9357b60 80540853 0000000a e1147008 0000001c nt!KeBugCheck2+0x574
    f9357b60 fbe93403 0000000a e1147008 0000001c nt!KiTrap0E+0x233
    WARNING: Stack unwind information not available. Following frames may be wrong.
    f9357c58 805759d1 ffb5c3b0 8111f318 811d9130 myfault+0x403
    f9357d00 8056e33c 00000090 00000000 00000000 nt!IopXxxControlFile+0x5e7
    f9357d34 8053d808 00000090 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
    f9357d34 7c92eb94 00000090 00000000 00000000 nt!KiFastCallEntry+0xf8
    0012f9f0 7c92d8ef 7c801671 00000090 00000000 ntdll!KiFastSystemCallRet
    0012f9f4 7c801671 00000090 00000000 00000000 ntdll!ZwDeviceIoControlFile+0xc
    0012fa54 004018c2 00000090 83360018 00000000 0x7c801671


    STACK_COMMAND:  kb

    FOLLOWUP_IP: //反汇编了发生错误指令的代码
    myfault+403
    fbe93403 8b06            mov     eax,dword ptr [esi]

    SYMBOL_STACK_INDEX:  4
    FOLLOWUP_NAME:  MachineOwner
    MODULE_NAME: myfault
    IMAGE_NAME:  myfault.sys
    DEBUG_FLR_IMAGE_TIMESTAMP:  43774e1d
    SYMBOL_NAME:  myfault+403
    FAILURE_BUCKET_ID:  0xD1_myfault+403
    BUCKET_ID:  0xD1_myfault+403
    Followup: MachineOwner
    //以上几段看名字就知道了,是以上信息的重复没有多大价值。
    四。总结
        通过以上的分析,知道了蓝屏的原因是Bugcheck D1引起的,是由于驱动程序读操作了过高的IRQL引起的。也知道了这个引发
    蓝屏的驱动程序是myfault.sys,属于notmyfaulf.exe的进程。还知道了蓝屏前bug程序myfault.sys的调用情况等多个有用信息,
    接着就可以在myfault.sys源程序中进行bug修改了。

     

     

    http://www.xhjdn.com/news/html/?299.html

    展开全文
  • Windbg-分析Windows蓝屏原因利器[转]下载地址先声明下,虽然用windbg诊断蓝屏之前网络上已经有人发过教程了,但就我而言, 学会使用windbg来诊断蓝屏也算是自己的原创吧。以前看一个微软专家的视频(微软专家张银奎...
  • Windows系统的蓝屏通常是由于发生了严重错误,其原因...这款名为BlueScreenView(电脑蓝屏信息)的免费小软件能够分解出Windows发生蓝屏崩溃后生成的“minidump”文件,使其容易阅读,从而帮助用户找出问题的症结所在。
  • 电脑蓝屏对照码

    2019-05-05 14:16:40
    比如冲击波和振荡波等病毒有时会导致Windows蓝屏死机, 因此查杀病毒必不可少. 同时一些木马间谍软件也会引发蓝屏, 所以最好再用相关工具进行扫描检查. 5.检查BIOS和硬件兼容性 对于新装的电脑经常出现蓝屏问题, 应该...
  • 这款名为BlueScreenView(电脑蓝屏信息)的免费小软件能够分解出Windows发生蓝屏崩溃后生成的“minidump”文件,使其容易阅读,从而帮助用户找出问题的症结所在
  • 我们在日常使用电脑的时候,偶尔会遇到令人不快的事情就是蓝屏死机,那么到底是什么原因...一、电脑蓝屏的概念电脑蓝屏,又叫蓝屏死机(英文:Blue Screen of Death,缩写为:BSoD),是指微软Windows 操作系统在无...
  • 用于查看Windows环境下系统自动转储的蓝屏文件 BlueScreenView scans all your minidump files created during 'blue screen of death' crashes, and displays the information about all crashes in one table. For...
  • https://blog.csdn.net/Tinna_zhang/article/details/18048389?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7Edefault-1.control&depth_1-utm_source=...
  • 问题描述 ...WdFilter.sys报错蓝屏主要是由win10系统更新后,系统不兼容,导致报错蓝屏。 解决方案 1、进入安全模式或者PE 重启电脑按F8进入安全模式或者PE 部分台式机进不去的话去百度其...
  • WINDOWS蓝屏代码大全

    千次阅读 2020-12-02 18:13:43
    完整的蓝屏错误代码大全详解 一个死机(BSOD)的蓝屏,技术上称为一个STOP错误,若在Windows遭受了严重的错误,被迫“停”的问题。 在任何Windows 操作系统中都会出现BSOD错误,包括Windows 10,Windows 8,Windows...
  • Windows蓝屏dump文件查看器

    千次阅读 2013-03-13 09:30:26
    Windbg-分析Windows蓝屏原因利器[转] 下载地址 先声明下,虽然用windbg诊断蓝屏之前网络上已经有人发过教程了,但就我而言, 学会使用windbg来诊断蓝屏也算是自己的原创吧。以前看一个微软专家的视频(微软专家...
  • windows蓝屏分析

    2021-01-20 15:40:34
    蓝屏后的 DMP文件拖到 windbg,执行 !analyze -v STOP代码 蓝屏的原因 00000001 BSOD意味着APC状态指数存在不匹配。BSOD错误代码0x00000001也可能在同一蓝色屏幕上显示“APC_INDEX_MISMATCH”。 0x00000002 这种...
  • Windows Server2008R2蓝屏,分析dmp文件

    千次阅读 2019-09-29 19:30:28
    使用Windbp PreView打开dmp文件后,在命令栏输入如下命令: !analyze -v 解析结果中蓝色字体为错误原因分析 转载于:https://www.cnblogs.com/MollyHan/p/11490859.html...
  • 蓝屏文件分析

    2015-01-10 18:31:45
    里面打开的软件可以分析出C:\Windows\Minidump文件夹下的蓝屏文件的内容,分析出来的内容最后一行就是导致蓝屏的罪魁祸首
  • BlueScreenView不需要任何安装过程或额外的DLL文件。开始使用它,只需运行可执行文件- BlueScreenView.exe BlueScreenView运行后,它会自动扫描您的小存储器转储文件文件夹并在上部窗格中显示所有意外事件的细节。 ...
  • Windows蓝屏代码及解决方案最全合集

    千次阅读 2020-11-23 16:21:51
    蓝屏故障并不少见,然多数用户对蓝屏代码知之甚少,一方面是读不懂英文字符,另一方面不理解专业术语,但蓝屏代码很多情况也确实为我们解决系统故障提供了一手线索。本文将深入、全面的剖析蓝屏故障中出现的各类错误...
  • WINDOWS蓝屏解析

    2014-09-15 20:25:50
    解析Windows因更新、安装软件或病毒引起重启蓝屏的具体文件及位置。
  • 电脑蓝屏,又叫蓝屏死机(Blue Screen of Death,简称BSOD),是微软的Windows系列操作系统在无法从一个系统错误中恢复过来时,为保护电脑数据文件不被破坏而强制显示的屏幕图像。Windows操作系统的蓝屏死机提示已经...
  • 蓝屏错误疑难解答适用于: Windows 10如果某个问题导致设备意外关机或重启,则可能会发生蓝屏错误(也称为停止错误)。你可能会看到一个蓝屏,同时显示消息“你的设备遇到了问题,需要重启”。注意如果你遇到黑屏或...
  • 1.需要使用的工具和文件opencore configuratorpropertreeOpenshell.efi(这个文件自行查看自己的efi里有没有,如果没有可以找一个efi拖到你这里)记得要把你安装的ubuntu或者Linux引导文件拖到efi文件里,才能进行...
  • windows 蓝屏修复

    2021-04-01 13:26:12
    输入bcdboot c:\windows /l zh-cn(注意后面不是一是小写L)注意斜杠方向当禁用自动修复之后,同常重启后电脑会显示出现错误的文件,一定要记住损坏文件的路径 然后按F1选微软软盘,按照之前操作再次进入操作界面...
  • window蓝屏查看工具

    2018-08-14 13:13:20
    微软windows操作系统蓝屏分析工具,可以分析操作系统蓝屏而生成的dump文件,将dump文件让此工具读取,可以分析出问题原因,可以分析服务器操作系统和个人操作系统
  • 项目场景: Windows系统 问题描述: 电脑突然开机失败,提示无法自动修复你的电脑
  • Windows10下visdom启动失败解决方案见: https://blog.csdn.net/qq_36941368/article/details/82288154。 本资源提供css、js和fonts下的所有文件,省得大家单个下载费劲。
  • 可使用途径:微信制作.url文件或其他文件,地址栏直接访问,做成html,exe等文件,xss利用等 url文件制作:https://baijiahao.baidu.com/s?id=1553137529313837&wfr=spider&for=pc url文件内核心代码为:...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 12,038
精华内容 4,815
关键字:

windows蓝屏文件