python launcher卸载后蓝屏_使用dump文件分析系统蓝屏原因

当系统崩溃在蓝屏瞬间,系统会形成一个扩展名为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

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

--------

相关资源:蓝屏修复工具.zip
表情包
插入表情
评论将由博主筛选后显示,对所有人可见 | 还能输入1000个字符
相关推荐
©️2020 CSDN 皮肤主题: 深蓝海洋 设计师:CSDN官方博客 返回首页