windebug的妙用

原创

wenxue_813 2012-08-10 08:54:02 博主文章分类：操作系统 ©著作权

文章标签 windebug 文章分类 运维

©著作权归作者所有：来自51CTO博客作者wenxue_813的原创作品，请联系作者获取转载授权，否则将追究法律责任

最近由于在公司使用dell 755pc机不支持虚拟化技术，就更换了一台计算机，而硬盘使用的还是我原来的。更换后再玩游戏时经常会出现卡住，过上一会机器就重启了。其实是蓝屏了，不过我把信息转储了，所有没有看到蓝屏。

在微软的网上下载<a href="http://msdn.microsoft.com/en-us/windows/hardware/gg463009">http://msdn.microsoft.com/en-us/windows/hardware/gg463009</a>

安装很简单，使用也很简单。

1.首先查找dump文件的存储位置。通过右键单击 [我的电脑] ---[属性]---[高级]---[启动和故障恢复]，点设置即可。也可以在事件查看器中看到之前故障时系统状态转储的位置
2.在相应的位置找到dump文件。
3.使用windows官方的的win debug工具进行分析。在kd> 提示符下输入!analyze -v，开始分析

我的机器是因为之前的显卡驱动没有删除，导致和现在显卡驱动冲突。卸载显卡驱动，重新安装就好了。

整个输出如下：
Loading Dump File [C:\WINDOWS\Minidump\Mini062811-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: C:\WINDOWS\Symbols
Executable search path is:
Unable to load p_w_picpath ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Windows XP Kernel Version 2600 (Service Pack 3) MP (2 procs) Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Machine Name:
Kernel base = 0x80800000 PsLoadedModuleList = 0x80886720
Debug session time: Tue Jun 28 17:15:23.421 2011 (GMT+8)
System Uptime: 0 days 1:01:48.210
Unable to load p_w_picpath ntoskrnl.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntoskrnl.exe
Loading Kernel Symbols
...............................................................
................................................................

Loading User Symbols
Mini Kernel Dump does not contain unloaded driver list
Unable to load p_w_picpath igxpdv32.DLL, Win32 error 0n2
*** WARNING: Unable to verify timestamp for igxpdv32.DLL
*** ERROR: Module load completed but symbols could not be loaded for igxpdv32.DLL
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck EA, {8a9dada8, 89e09740, 89d022d8, 1}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** WARNING: Unable to verify timestamp for igxpgd32.dll
*** ERROR: Module load completed but symbols could not be loaded for igxpgd32.dll
*** WARNING: Unable to verify timestamp for igxprd32.dll
*** ERROR: Module load completed but symbols could not be loaded for igxprd32.dll
*** WARNING: Unable to verify timestamp for win32k.sys
Unable to load p_w_picpath watchdog.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for watchdog.sys
Probably caused by : igxpdv32.DLL ( igxpdv32+ab0 )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

THREAD_STUCK_IN_DEVICE_DRIVER (ea)
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 (OS builds <= 3790) 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: 8a9dada8, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 89e09740, Pointer to a DEFERRED_WATCHDOG object.
Arg3: 89d022d8, Pointer to offending driver name.
Arg4: 00000001, Number of times this error occurred. If a debugger is attached,
this error is not always fatal -- see DESCRIPTION below. On the
blue screen, this will always equal 1.

Debugging Details:
------------------

FAULTING_THREAD: 8a9dada8

DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

PROCESS_NAME: explorer.exe

LAST_CONTROL_TRANSFER: from bf0b71cc to bf096ab0

STACK_TEXT:
WARNING: Stack unwind information not available. Following frames may be wrong.
b8400bc0 bf0b71cc 8a18d000 0282d6a1 8a112000 igxpdv32+0xab0
b8400bc4 8a18d000 0282d6a1 8a112000 b8400c14 igxpdv32+0x211cc
b8400bc8 0282d6a1 8a112000 b8400c14 8a18d000 0x8a18d000
b8400bcc 8a112000 b8400c14 8a18d000 e229d010 0x282d6a1
b8400bd0 b8400c14 8a18d000 e229d010 bf0b7219 0x8a112000
b8400bd4 8a18d000 e229d010 bf0b7219 8a112000 0xb8400c14
b8400c14 bf07c67b e4f30638 e4f30638 b8400c38 0x8a18d000
b8400c24 bf086d34 e317b338 00000000 00000000 igxpgd32+0x1167b
b8400c38 bf060c2e e317b338 00000000 00000000 igxpgd32+0x1bd34
b8400c54 bf8a61a6 e317b338 00000000 00000000 igxprd32+0x7c2e
b8400c90 bf8053e3 e317b338 00000000 00000000 win32k!PDEVOBJ::vProfileDriver+0x321
b8400ca4 bf8388e6 e317b338 00000000 00000000 win32k!DC::vUpdate_VisRect+0x24
b8400ec0 bf071f67 e317b338 e1d4c008 e1ad75a4 win32k!xxxMoveWindow+0x4f
b8400ee4 bf071d1b e317b338 e229d010 e1ad75a4 igxpgd32+0x6f67
b8400f0c bf071973 e317b338 e229d010 e1ad75a4 igxpgd32+0x6d1b
b84010f4 bf0864fd e317b338 e229d010 e1ad75a4 igxpgd32+0x6973
b840111c bf06046f e317b338 e229d010 e1ad75a4 igxpgd32+0x1b4fd
b84011d8 bf805a36 e317b338 e229d010 e1ad75a4 igxprd32+0x746f
b8401224 bf816dd1 e317b338 e229d010 e1ad75a4 win32k!AllocateObject+0x68
b8401264 bf817318 e216a010 e229d010 e1ad75a4 win32k!SURFREFAPI::SURFREFAPI+0x109
b84012f0 bf8170c0 e317b338 e216a010 e1ad75a4 win32k!SURFREFAPI::SURFREFAPI+0x1b3
b8401314 b8401488 e317b328 00000000 00000000 win32k!SURFACE::pfnDrawStream+0xd
b8401350 bf8175ec e317b338 e216a010 e1ad75a4 0xb8401488
b84013ac bf817a46 e317b338 e216a010 e1ad75a4 win32k!NtGdiDrawStream+0xb3
b8401410 bf817e2d b8401534 e1ad75a4 e216a000 win32k!GreDrawStream+0x185
b8401538 bf8176d1 01010056 00000000 00000000 win32k!GreDrawStream+0x441
b8401680 8086a67c 01010056 00000060 00fcf4f8 win32k!NtGdiDrawStream+0x71
b8401694 7c92e514 badb0d00 00fcf378 00fcfa04 nt!RtlIpv4StringToAddressExW+0xfd
b84016a8 badb0d00 00fcf9bc 00000202 00fcfc64 0x7c92e514
b84016ac 00fcf9bc 00000202 00fcfc64 00000001 0xbadb0d00
b84016b0 00000000 00fcfc64 00000001 00000000 0xfcf9bc

STACK_COMMAND: .thread 0xffffffff8a9dada8 ; kb

FOLLOWUP_IP:
igxpdv32+ab0
bf096ab0 56              push    esi

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: igxpdv32+ab0

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: igxpdv32

IMAGE_NAME: igxpdv32.DLL

DEBUG_FLR_IMAGE_TIMESTAMP: 47f3a316

FAILURE_BUCKET_ID: 0xEA_IMAGE_igxpdv32.DLL_DATE_2008_04_02

BUCKET_ID: 0xEA_IMAGE_igxpdv32.DLL_DATE_2008_04_02

Followup: MachineOwner
---------