unionjosh

Hi,

In the last two weeks I've been having a problem I've never had before.

Sometimes the comp won't comp back out of hibernate, so I turned off hibernate. I still have the monitor shut off, but even then, sometimes it won't come back. Sometimes it'll lock up on the screen saver. It's now locking up on me about once a day.

Another problem i've been having, which I think has stopped due to reinstallation of drivers was that the monitor would blip a few times, then come back, and about 5 minutes later everything would lock up. Then the monitor would go blank, and nothing happened. For some strange reason, my DVD and CD drives would start blinking.

As i said, i think the last problem has stopped (hopefully), but I'm still locking up. I can't get a dump because it's not restarting. I got a dump once, which led me to the video driver.

is my video card dying or could it be another issue entirely?

I'm running windows XP SP3 on a AMD Athlon 64 Processor with 3Gigs of ram.
If anyone can help, I'd really appreciate it.

Thanks,
Josh

This is the dump I got:


Microsoft (R) Windows Debugger Version 6.10.0003.233 X86
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [C:\WINDOWS\Minidump\Mini081809-01.dmp]
Mini Kernel Dump File: Only registers and stack trace are available

Symbol search path is: G:\Windows Symbols
Executable search path is:
Unable to load image \WINDOWS\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x80554040
Debug session time: Mon Aug 17 22:29:22.578 2009 (GMT-4)
System Uptime: 1 days 13:12:03.167
Unable to load image \WINDOWS\system32\ntkrnlpa.exe, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ntkrnlpa.exe
Loading Kernel Symbols
...............................................................
...............................................................
Loading User Symbols
Loading unloaded module list
................................
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 100000EA, {8975eda8, 8a327008, b84e3cb4, 1}

*** WARNING: Unable to verify timestamp for mssmbios.sys
*** WARNING: Unable to verify timestamp for watchdog.sys
*** WARNING: Unable to verify timestamp for win32k.sys
*** WARNING: Unable to verify timestamp for nv4_disp.dll
Probably caused by : nv4_disp.dll ( nv4_disp!bOglCreateWindowTrackingObj+9d )

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

kd> !analyze -K

Unknown option '-K'
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 100000EA, {8975eda8, 8a327008, b84e3cb4, 1}

Probably caused by : nv4_disp.dll ( nv4_disp!bOglCreateWindowTrackingObj+9d )

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

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: 8975eda8, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 8a327008, Pointer to a DEFERRED_WATCHDOG object.
Arg3: b84e3cb4, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).

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


DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT

CUSTOMER_CRASH_COUNT: 1

BUGCHECK_STR: 0xEA

LAST_CONTROL_TRANSFER: from 804f9030 to 805417bf

STACK_TEXT:
b2eb4354 804f9030 b84e3b40 b84e3b70 00000000 nt!KiUnlockDispatcherDatabase+0x87
b2eb4358 b84e3b40 b84e3b70 00000000 b2eb465c nt!KeSetEventBoostPriority+0x2
WARNING: Frame IP not in any known module. Following frames may be wrong.
b2eb4368 b83d8a67 b84e3b94 00000000 00000000 0xb84e3b40
b2eb465c 804fdaf1 b84e3b40 b2eb46a8 b2eb469c watchdog!WatchdogKernelApc+0x13b
b2eb46ac 80500d04 00000000 00000000 00000000 nt!KiDeliverApc+0xc3
b2eb46bc 8975ee18 8975eda8 804f9d72 00000001 nt!KiUnlinkThread+0x2
b2eb46ec bf85a607 00000000 00000000 00000000 0x8975ee18
b2eb4708 bd036a6d 8a3fd998 b2eb473c b45a9000 win32k!NtUserCallHwnd+0x40
b2eb4714 b45a9000 b2eb47d8 0000000e 00000000 nv4_disp!bOglCreateWindowTrackingObj+0x9d
b2eb4720 00000000 00020afe 00020af7 b86fa12e 0xb45a9000


STACK_COMMAND: kb

FOLLOWUP_IP:
nv4_disp!bOglCreateWindowTrackingObj+9d
bd036a6d ?? ???

SYMBOL_STACK_INDEX: 8

SYMBOL_NAME: nv4_disp!bOglCreateWindowTrackingObj+9d

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nv4_disp

IMAGE_NAME: nv4_disp.dll

DEBUG_FLR_IMAGE_TIMESTAMP: 4a5ce1b1

FAILURE_BUCKET_ID: 0xEA_IMAGE_nv4_disp.dll_DATE_2009_07_14

BUCKET_ID: 0xEA_IMAGE_nv4_disp.dll_DATE_2009_07_14

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