计算机蓝屏分析报告,终于有蓝屏报告了，请帮忙分析一下

蓝屏了一个月了，痛苦了一个月了，终于把蓝屏报告弄出来了，之前没有DMP文件。废话不多说，贴上分析结果，各位一定要帮我分析下，以前从来不蓝屏的。

Microsoft (R) Windows Debugger Version 6.11.0001.404 X86

Copyright (c) Microsoft Corporation. All rights reserved.

Loading Dump File [C:\WINDOWS\MEMORY.DMP]

Kernel Complete Dump File: Full address space is available

Symbol search path is: SRV*F:\temp*http://msdl.microsoft.com/download/symbols

Executable search path is:

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

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 2600.xpsp_sp3_gdr.100427-1636

Machine Name:

Kernel base = 0x804d8000 PsLoadedModuleList = 0x8055e720

Debug session time: Mon Jan  3 22:54:21.750 2011 (GMT+8)

System Uptime: 0 days 0:31:09.421

Loading Kernel Symbols

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

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

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

Loading User Symbols

Loading unloaded module list

...........

*** WARNING: Unable to verify timestamp for ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ

*** ERROR: Module load completed but symbols could not be loaded for ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ ﳼ

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

*                                                                             *

*                        Bugcheck Analysis                                    *

*                                                                             *

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

Use !analyze -v to get detailed debugging information.

BugCheck EA, {890f9da8, 89b33378, ba4e3cbc, 1}

*** WARNING: Unable to verify timestamp for mssmbios.sys

*** ERROR: Module load completed but symbols could not be loaded for mssmbios.sys

Probably caused by : ????????????????????????????????? ( _________________________________+3337 )

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: 890f9da8, Pointer to a stuck thread object.  Do .thread then kb on it to find

the hung location.

Arg2: 89b33378, Pointer to a DEFERRED_WATCHDOG object.

Arg3: ba4e3cbc, 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:  890f9da8

DEFAULT_BUCKET_ID:  GRAPHICS_DRIVER_FAULT

BUGCHECK_STR:  0xEA

PROCESS_NAME:  System

LAST_CONTROL_TRANSFER:  from 00000000 to 806edf73

STACK_TEXT:

ba4e3ba4 ba41b337 000000ea 890f9da8 89b33378 nt!KeBugCheckEx+0x1b

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

ba4e3d7c 8053979d ba4193a4 00000000 89bec910 _________________________________+0x3337

ba4e3dac 805d0f62 ba4193a4 00000000 00000000 nt!ExpWorkerThread+0xef

ba4e3ddc 8054712e 805396ae 00000000 00000000 nt!PspSystemThreadStartup+0x34

00000000 00000000 00000000 00000000 00000000 nt!KiThreadStartup+0x16

STACK_COMMAND:  kb

FOLLOWUP_IP:

_________________________________+3337

ba41b337 0000            add     byte ptr [eax],al

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  _________________________________+3337

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: _________________________________

IMAGE_NAME:  ?????????????????????????????????

DEBUG_FLR_IMAGE_TIMESTAMP:  0

FAILURE_BUCKET_ID:  0xEA_IMAGE_?????????????????????????????????

BUCKET_ID:  0xEA_IMAGE_?????????????????????????????????

Followup: MachineOwner

---------