精华内容
下载资源
问答
  • 当系统崩溃在蓝屏瞬间,系统会形成一个扩展名为dmp的存储器转储文件,默认存储位置为C:\WINDOWS\Minidmp。A.右击“我的电脑”选择“属性”,在“系统属性”对话框中选择“高级”B.在“启动和故障恢复”中选择...

    当系统崩溃在蓝屏瞬间,系统会形成一个扩展名为dmp的存储器转储文件,默认存储位置为C:\WINDOWS\Minidmp。

    A.右击“我的电脑”选择“属性”,在“系统属性”对话框中选择“高级”

    a22ac0a73800a2bf91931b065bea8bd4.png

    B.在“启动和故障恢复”中选择“设置”,具体设置如下图所示

    1585054eaba382cd55b2606f30b6b38b.png

    什么是windebug

    windebug是微软发布的一款相当优秀的源码级(source-level)调试工具,可以用于Kernel模式调试和用户模式调试,还可以调试Dump文件。

    最新版安装方法(此方法为在线安装)

    B.安装netFramework2.0

    C.运行1中下载的winsdk_web.exe

    320cca7f7b7e05ed8f8067173d19710e.png

    3fd5c4d46fd83162590e09af12802bdd.png

    52451748d733bf906afc80ab4267297f.png

    853e79111035aa627419a0ac155058b1.png

    a0b104639dd5cf903a38714ab1495bdc.png

    8e3e3ea61f8a986d2b680058e00150a5.png

    27fea3763dab7d0dbf1f6ecc01e3dade.png

    4c8abd5a0755b4e09e71684c91b6f902.png

    f069f276b380e3ae0deeb14bec61e329.png

    dea66ac14ba52179c9b573c54c0ddf1c.png

    ad4e87a6c6b49f9d02b6f8f5ece2425e.png

    的symbol符号文件的路径配置

    为windebug设置symbol路径可以提高对dump文件分析的准确性,给我们更多有价值的错误信息。

    A.在http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx根据实际需要下载相应的版本

    B.安装下载的symbol符号文件

    0e7b8c1da1bd049c49b29a4da20f558f.png

    fbb3f4b0576768e0b944a42aae354a3e.png

    1cd995290c90c3132a6438dd248b0966.png

    9ec44a6e8ba1df3d46b5a512367bf679.png

    53ea58a04afdd87488d845e1b0113502.png

    3199a9e3709522c1667c9b715a5e18af.png

    37e55d1e03b679378bed24df6f0411fc.png

    3137914fc847826ada6380d7ec8884bf.png

    3565f1affaba90f9d8f517f61708f423.png

    eaf1cedaf1ed3150bf812a2e74534218.png

    详细代码如下

    Loading Dump File [C:\Documents and Settings\test-pc\桌面\dump文件\Mini102011-01.dmp]

    Mini Kernel Dump File: Only registers and stack trace are available

    Symbol search path is: C:\WINDOWS\Symbols;SRV*C:\Windows\symbols*http://msdl.microsoft.com/download/symbols

    Executable search path is:

    Windows XP Kernel Version 2600 (Service Pack 3) MP (4 procs) Free x86 compatible

    Product: WinNt, suite: TerminalServer SingleUserTS

    Built by: 2600.xpsp_sp3_gdr.101209-1647

    Machine Name:

    Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055e720

    Debug session time: Thu Oct 20 14:37:16.343 2011 (UTC + 8:00)

    System Uptime: 0 days 0:00:43.312

    Loading Kernel Symbols

    ...............................................................

    ..........................................

    Loading User Symbols

    Loading unloaded module list

    ....

    *** WARNING: Unable to verify timestamp for nv4_disp.dll

    *** ERROR: Module load completed but symbols could not be loaded for nv4_disp.dll

    *******************************************************************************

    **

    *Bugcheck Analysis*

    **

    *******************************************************************************

    Use !analyze -v to get detailed debugging information.

    BugCheck 100000EA, {88a18908, 88ced810, b84fbcbc, 1}

    ERROR - could not read driver name for bugcheck parameter 3

    Probably caused by : nv4_disp.dll ( nv4_disp+28526 )

    Followup: MachineOwner

    ---------

    3: kd> !analyze -v

    *******************************************************************************

    **

    *Bugcheck Analysis*

    **

    *******************************************************************************

    THREAD_STUCK_IN_DEVICE_DRIVER_M (100000ea)

    The device driver is spinning in an infinite loop, most likely waiting for

    hardware to become idle. This usually indicates problem with the hardware

    itself or with the device driver programming the hardware incorrectly.

    If the kernel debugger is connected and running when watchdog detects a

    timeout condition then DbgBreakPoint() will be called instead of KeBugCheckEx()

    and detailed message including bugcheck arguments will be printed to the

    debugger. This way we can identify an offending thread, set breakpoints in it,

    and hit go to return to the spinning code to debug it further. Because

    KeBugCheckEx() is not called the .bugcheck directive will not return bugcheck

    information in this case. The arguments are already printed out to the kernel

    debugger. You can also retrieve them from a global variable via

    "dd watchdog!g_WdBugCheckData l5" (use dq on NT64).

    On MP machines it is possible to hit a timeout when the spinning thread is

    interrupted by hardware interrupt and ISR or DPC routine is running at the time

    of the bugcheck (this is because the timeout's work item can be delivered and

    handled on the second CPU and the same time). If this is the case you will have

    to look deeper at the offending thread's stack (e.g. using dds) to determine

    spinning code which caused the timeout to occur.

    Arguments:

    Arg1: 88a18908, Pointer to a stuck thread object.Do .thread then kb on it to find

    the hung location.

    Arg2: 88ced810, Pointer to a DEFERRED_WATCHDOG object.

    Arg3: b84fbcbc, Pointer to offending driver name.

    Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

    Debugging Details:

    ------------------

    ERROR - could not read driver name for bugcheck parameter 3

    FAULTING_THREAD:88a18908

    FAULTING_IP:

    nv4_disp+28526

    bd03a526 ?????

    IMAGE_NAME:nv4_disp.dll

    DEBUG_FLR_IMAGE_TIMESTAMP:4bb7e5d1

    MODULE_NAME:nv4_disp

    FAULTING_MODULE: bd012000 nv4_disp

    DEFAULT_BUCKET_ID:GRAPHICS_DRIVER_FAULT

    CUSTOMER_CRASH_COUNT:1

    BUGCHECK_STR:0xEA

    PROCESS_NAME:csrss.exe

    LAST_CONTROL_TRANSFER:from e3a33010 to bd03a526

    STACK_TEXT:

    WARNING: Stack unwind information not available. Following frames may be wrong.

    b816758c e3a33010 e3a33010 e3a33010 00000080 nv4_disp+0x28526

    b8167590 e3a33010 e3a33010 00000080 bd04e0b0 0xe3a33010

    b8167594 e3a33010 00000080 bd04e0b0 00000000 0xe3a33010

    b8167598 00000000 bd04e0b0 00000000 00000000 0xe3a33010

    STACK_COMMAND:.thread 0xffffffff88a18908 ; kb

    FOLLOWUP_IP:

    nv4_disp+28526

    bd03a526 ?????

    SYMBOL_STACK_INDEX:0

    SYMBOL_NAME:nv4_disp+28526

    FOLLOWUP_NAME:MachineOwner

    FAILURE_BUCKET_ID:0xEA_IMAGE_nv4_disp.dll_DATE_2010_04_04

    BUCKET_ID:0xEA_IMAGE_nv4_disp.dll_DATE_2010_04_04

    Followup: MachineOwner

    通过红色的代码可以分析出这个蓝屏是由于显卡驱动引起的

    --------

    展开全文
  • 告诉Win10蓝屏dump文件分析工具|BlueScreenView怎么用?由于Win10系统蓝屏不再显示详细信息让很多用户不知道问题所在,导致很多人很苦恼,北漂哥给你推荐一款软件帮你解决问题。北漂哥说说用法吧,相信你有收获;第...

    告诉Win10蓝屏dump文件分析工具|BlueScreenView怎么用?

    由于Win10系统蓝屏不再显示详细信息让很多用户不知道问题所在,导致很多人很苦恼,北漂哥给你推荐一款软件帮你解决问题。

    北漂哥说说用法吧,相信你有收获;

    94f2edc9e030d88110d4c293edb995c0.png

    第一步:

    双击BlueScreenView.exe,运行蓝屏检测程序。

    e043cbc4c46b5b3fac4ef0e087a36651.png

    第二步:

    运行后自动扫描您的当前小存储器转储文件文件夹并列出显示所有崩溃转储文件,包括崩溃转储日期、时间和崩溃细节;

    3a1914eb0245bca7079d509673eb175e.png

    第三步:

    可以模拟Windows崩溃时显示的蓝色屏幕进行信息显示,在“选项”菜单的“下层窗格模式”选择“以XP样式显示蓝底白字画面”;

    f45447e19fa5a7a3ac0d6a133f1b3182.png

    接下来即可显示模拟蓝屏画面了:

    8f1cb4c4906ccb0c83e63a5829ff653e.png

    第四步:

    BlueScreenView枚举崩溃堆栈中的内存地址,以帮助您找到其中可能导致崩溃的驱动、模块;

    2c85c945ffcca43ebe872c3a1f02f033.png

    第五步:

    只要您在高级选项里选择正确的转储文件夹,BlueScreenView也可让您查看另一个Windows中的崩溃数据。在“选项”菜单选择“高级选项”;

    cc455a5a7431478bdd1a2d9768a1d74c.png

    第六步:

    然后就可以从指定的路径载入其他Dump文件(比如从其他电脑拷贝来的)进行分析;

    b074d52653a466f3a1e82da2a89772ed.png

    第七步:

    BlueScreenView自动定位崩溃转储中出现的驱动,并提取它们的版本资源信息,包括产品名称、文件版本、公司和文件描述。

    68899661880d807c27235c1640f21662.png

    注:希望你看到这款软件使用方法后,对你发愁问题能得以解决,希望在以后日子里大家能和我多

    多交流共同进步,通过此平台。

    展开全文
  • 驱动蓝屏后简单的分析dump文件

    千次阅读 2014-01-09 19:38:52
    1: kd> !analyze–v Debugging Details: ------------------   *** ERROR: Moduleload completed but symbols could not be loaded for ntnfapi.sys ...EXCEPTION_CODE:(NTSTATUS) 0xc0000005 - 0x%08lx ...

    1: kd> !analyze–v

    Debugging Details:

    ------------------

     

    *** ERROR: Moduleload completed but symbols could not be loaded for ntnfapi.sys

     

    EXCEPTION_CODE:(NTSTATUS) 0xc0000005 - 0x%08lx

     

    FAULTING_IP: (FAULTING_IP表示引起这个错误的指令的指针。)

    ntnfapi+1f0e

    a4546f0e 8b7014          mov     esi,dword ptr [eax+14h]

     

    TRAP_FRAME:  a2a72aa0-- (.trap 0xffffffffa2a72aa0)

    ErrCode = 00000000

    eax=00000000ebx=886048e0 ecx=a2a72b3c edx=87f1f790esi=88604828 edi=00000006

    eip=a4546f0e esp=a2a72b14 ebp=a2a72b18iopl=0         nv up ei ng nz na po nc

    cs=0008  ss=0010 ds=0023  es=0023  fs=0030 gs=0000             efl=00010282

    ntnfapi+0x1f0e:

    a4546f0e 8b7014          mov     esi,dword ptr [eax+14h]ds:0023:00000014=????????

    Resetting defaultscope

     

    DEFAULT_BUCKET_ID:  DRIVER_FAULT(DEFAULT_BUCKET_ID字段显示这个错误属于哪一类。)

     

    BUGCHECK_STR:  0x8E

     

    PROCESS_NAME:  LMS.exe(PROCESS_NAME字段显示的是产生这个异常的进程名字。)

     

    ANALYSIS_VERSION:6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre

     

    LAST_CONTROL_TRANSFER:  from 804ff817 to 804faf33

     

    STACK_TEXT:  (STACK_TEXT显示的是错误模块的栈的回溯(stack trace)

    a2a72668 804ff817 0000008e c0000005 a4546f0e nt!KeBugCheckEx+0x1b

    a2a72a3080543085 a2a72a4c 00000000 a2a72aa0nt!KiDispatchException+0x3b1

    a2a72a9880543036 a2a72b18 a4546f0e badb0d00nt!CommonDispatchException+0x4d

    a2a72ab0 a45458c500000007 87e41008 87e410e4 nt!Kei386EoiHelper+0x18a

    WARNING: Stackunwind information not available. Following frames may be wrong.

    a2a72b18 a4545cf488468d48 88604828 886048e0 ntnfapi+0x8c5

    a2a72b4c804f018f 87f1f790 88468d48 00000002 ntnfapi+0xcf4

    a2a72c5080580982 87e420e4 87b6c78887e42008 nt!IopfCallDriver+0x31

    a2a72c64805817f7 8857c220 87e42008 87b6c788 nt!IopSynchronousServiceTail+0x70

    a2a72d00 8057a274 00000228 0000025c00000000 nt!IopXxxControlFile+0x5c5

    a2a72d34 8054261c 00000228 0000025c 00000000 nt!NtDeviceIoControlFile+0x2a

    a2a72d34 7c92e4f400000228 0000025c 00000000nt!KiFastCallEntry+0xfc

    007ff6ac 00000000 00000000 00000000 000000000x7c92e4f4

     

     

    STACK_COMMAND:  kb(STACK_COMMAND字段的意思是上面的这两个命令(.excr,kb)可以获取STACK_TEXT,你可以使用这两个命令再次的显示栈或相关的栈信息.)

     

    FOLLOWUP_IP:

    ntnfapi+1f0e

    a4546f0e 8b7014          mov     esi,dword ptr [eax+14h]

     

    SYMBOL_STACK_INDEX:  0

     

    SYMBOL_NAME:  ntnfapi+1f0e

    FOLLOWUP_NAME:  MachineOwner

    MODULE_NAME:ntnfapi

    IMAGE_NAME:  ntnfapi.sys

    DEBUG_FLR_IMAGE_TIMESTAMP:  51830c23

    (!analyze判断出引起错误的指令,它会显示在FOLLOWUP_IP字段。

    SYMBOL_NAME,MODULE_NAME,IMAGE_NAMEDBG_FLR_IMAGE_TIMESTAMP显示的是这个指令对应的

    符号, 模块, 映像名和 映像时间戳.)

    FAILURE_BUCKET_ID:  0x8E_ntnfapi+1f0e

     

    BUCKET_ID:  0x8E_ntnfapi+1f0e

    (BUCKET_ID字段显示的是错误的具体分类,这个分类会帮助调试器判断该显示的其他分析信息)

    ANALYSIS_SOURCE:  KM

     

    FAILURE_ID_HASH_STRING:  km:0x8e_ntnfapi+1f0e

     

    FAILURE_ID_HASH:  {2495e343-dd52-ba6c-8106-c4e681c2422b}

     

    Followup:MachineOwner

    ---------


    原因:
    1.使用Inter主板的PC,安装了软件及驱动。
      Intel(R) Management Engine Components,简称 InterAMT
      InterAMT中的服务程序,LMS.exe和UNS.exe每隔10秒,通过网卡发送“非操作系统标准”的指令和数据包。
      导致LPS的网络行为监控组件错误。
     
    2.我们自己写的网络行为驱动,未对非标准的指令进行保护性处理。
     
    解决方案:
    方案一:(临时方案)
    1.禁止系统服务
      “Intel(R) Management and Security Application Local Management Service”
       简称:LMS
     
      或者,将exe改名,不允许系统启动exe:
      C:\Program Files\Intel\Intel(R) Management Engine Components\LMS\LMS.exe
      C:\Program Files\Intel\Intel(R) Management Engine Components\UNS\UNS.exe
     
      备注:InterAMT是Inter公司,基于主板硬件,让管理员远程管理客户端的系统组件,现在很少有人使用

    方案二:
    1.修改我们自己的网络行为驱动,增加容错保护措施。



     

    展开全文
  • 我们以收集一款收费软件引起...若网吧之前已经存在日志目录并且日志较大,可以先删除之前的日志文件,重现问题再提取新日志2、计费客户端日志:在客户端system32目录下手动创建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。



    展开全文
  • 为了分析蓝屏,我们至少要取出dump文件。那么在循环蓝屏的情况下,怎样才能取出dump文件呢? 本文就将介绍一种VMware虚拟机循环蓝屏情况下取dump文件的方法。 1、在该虚拟机蓝屏的时候,将其挂起 挂起,在...
  • 蓝屏dump调试

    千次阅读 2012-03-05 21:40:47
    1、在虚拟机中设置故障恢复存储方式 ...4、重启虚拟机,dmp文件存储在widows目录下,复制到主机   5、在主机中用windbg打开dmp   6、加载启动分析   7、打开Callstackquery错误所在行
  • dump文件分析笔记

    2019-05-23 23:01:34
    一般内核开发,选核心内存转储即可,下面就是生成文件的位置,为了学习把自动重新启动点掉,不然蓝屏后系统会自动重启。 下面写个蓝屏驱动让其发生BAD_POOL_CALLER(如果造成蓝屏的驱动是随系统启动而启动,会反复...
  • 前几天分享了一个关于如何抓蓝屏Dump的帖子,今天再和大家分享一个使用WinDbg来抓取程序崩溃的Dump。不过还是先来段废话,为什么要学抓Dump?有啥用?因为有了Dump后,我们可以很迅速的解决问题,比如说IE崩溃,QQ...
  • 使用WinDbg抓取程序报错的Dump文件,例如抓取IE崩溃的Dump,教程 前几天分享了一个关于如何抓蓝屏Dump的帖子,今天再和大家分享一个使用WinDbg来抓取程序崩溃的Dump。不过还是先来段废话,为什么要学抓Dump?有啥用...
  • 利用windbg分析dump文件

    万次阅读 2013-04-12 14:54:28
    这里主要记录利用windbg来分析windows蓝屏时所产生的内存转储文件*.dmp。 1,下载: http://www.microsoft.com/whdc/devtools/debugging/default.mspx 2,配置symbol path: windows程序在编译生成,会产生...
  • 求Windows的dump文件分析.我电脑重装系统偶尔会突然卡住,然后只能重启.重启出现的错误报告是蓝屏错误报告,可是没有蓝屏啊,是一直卡住.这是我用windbg分析出来的报告,上面说是hardware错误,而且是genuine intel...
  • 前言细心的小伙伴可能注意到了,我在上一篇介绍抓取转储文件的工具的文章 —— 你需要知道的 N 种抓取 dump 的工具 中提到了: 如果用 64 位的 windbg 附加到 32 位目标进程,直接执行.dump 命令生成的转储文件会 ...
  • 蓝屏dmp查看器

    热门讨论 2011-09-26 15:29:04
    蓝屏dmp查看器 ,可以用来查看蓝屏后抓到的 dump 文件信息
  • 这里主要记录利用windbg来分析windows蓝屏时所产生的内存转储文件*.dmp。1,下载:http://www.microsoft.com/whdc/devtools/debugging/default.mspx 2,配置symbol path:windows程序在编译生成,会产生一些.exe,...
  • 设置系统蓝屏方法

    2018-08-01 18:15:19
    好好的系统为毛要整蓝屏~ because 有时候程序崩溃,导致整个系统hang住(卡死),只能...生成完整的dump文件必须保证c盘剩余空间够用,还要保证蓝屏后系统自动重新启动,系统没有自动重启要手动关闭再启动,否则...
  • Dump分析实例

    2021-01-15 15:44:11
    通俗地理解,dump文件是程序发生异常甚至崩溃时,保存当时程序运行状态的文件,主要用来分析程序崩溃原因或蓝屏原因。 如何生成dump文件? 方法一:使用任务管理器 前提:程序运行崩溃,没有自动退出的情况下。 ...
  • Windbg蓝屏故障排除

    2013-01-15 11:04:50
    最近蓝屏的朋友不少,其解决方法无过于提供蓝屏代码、截屏或提供dump文件。其实蓝屏的关键问题在于找到引发蓝屏故障的文件,找到文件按图索骥来排除故障。这里不推荐提供蓝屏代码的方法,因为不同原因会引起相同...
  • 昨天测试组报了一个蓝屏BUG,拿到dump文件后,分析发现可能是由于键盘引起的。所以这到底是键盘固件还是windows键盘kbdclass.sys引起的,这就不清楚了,我固计是固件的锅更大吧。 有兴趣的同学可以加QQ群952873936...
  • win7升级win10体验好很多,但是周期性蓝屏的问题,真的让人很头痛,幸好没有发生在我写东西的时候,不然我估计早就放弃了。其实我是有想法想退回win7或者重新装win10,但是我系统有很多软件,我不太想重装,我还想...
  • 用CrashDump定位应用错误

    千次阅读 2013-03-19 10:47:39
    通常,在驱动的世界里面,一旦我们的驱动有BUG,导致系统蓝屏,往往我们需要靠OS生成的CrashDump文件来进行事分析。但是事实上我们针对应用程序同样也能生成CrashDump。在某些情形下,我们必须在应用中主动生成...
  • 刚进系统不到5秒 就出现蓝屏错误画面 错误信息:hooksys .sys文件出错, 然后dump内存 ,只有等待系统统到100 自动从启。 初步认为是瑞星杀毒软件与SP1产生了冲突,本想进入系统删了瑞星看看是否还会出现蓝屏 ...
  • 操作系统在遇到致命错误导致崩溃时,并不是直接挂掉,而是会记录下当时内存中的数据,将其存储成为dump文件,并用一串蓝屏代码向用户做出提示。 一、如何获取DUMP文件 右键点击“我的电脑”,选“属性→高级→启动和...

空空如也

空空如也

1 2 3 4
收藏数 74
精华内容 29
关键字:

蓝屏后dump文件