Zaraz postaram sie wywolac ten bluee screen i przepisac błąd. Teraz ten bluee screen nie wyskakuje, niewiem czy uda mi sie to zrobic, problem jest chyba ze sterownikami od karty graficznej wyskakuje jakis błąd nv4_disp.dll
Dodano Dzisiaj, 10:04:Microsoft Debugging Tools x86
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini042510-07.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
Debug session time: Sun Apr 25 14:03:25.953 2010 (GMT+2)
System Uptime: 0 days 0:06:03.541
Loading Kernel Symbols
...............................................................
............................................................
Loading User Symbols
Loading unloaded module list
........
Unable to load image ALCXSENS.SYS, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ALCXSENS.SYS
*** ERROR: Module load completed but symbols could not be loaded for ALCXSENS.SYS
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 100000D1, {170, 2, 0, f66193a0}
Probably caused by : ALCXSENS.SYS ( ALCXSENS+543a0 )
Followup: MachineOwner
---------
Mam nadzieje ze to jest to. Ten błąd ze sterami do karty graficznej juz sie nie pojawia, ale jakby byl to podam z niego te dane.
Dodano Dzisiaj, 10:39:Ok mam ten 2 zrzut pamieci fizycznej:
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
Loading Dump File [C:\WINDOWS\Minidump\Mini050110-05.dmp]
Mini Kernel Dump File: Only registers and stack trace are available
Symbol search path is: SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows XP Kernel Version 2600 (Service Pack 3) UP Free x86 compatible
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 2600.xpsp.080413-2111
Machine Name:
Kernel base = 0x804d7000 PsLoadedModuleList = 0x8055b1c0
Debug session time: Sat May 1 10:13:20.593 2010 (GMT+2)
System Uptime: 0 days 0:06:39.179
Loading Kernel Symbols
...............................................................
.......................................................
Loading User Symbols
Loading unloaded module list
........
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************
Use !analyze -v to get detailed debugging information.
BugCheck 100000EA, {83318da8, 837e9ce0, f7a99cb4, 1}
*** WARNING: Unable to verify timestamp for nv4_mini.sys
*** ERROR: Module load completed but symbols could not be loaded for nv4_mini.sys
Probably caused by : nv4_mini.sys ( nv4_mini+5bd24 )
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: 83318da8, Pointer to a stuck thread object. Do .thread then kb on it to find
the hung location.
Arg2: 837e9ce0, Pointer to a DEFERRED_WATCHDOG object.
Arg3: f7a99cb4, Pointer to offending driver name.
Arg4: 00000001, Number of times "intercepted" bugcheck 0xEA was hit (see notes).
Debugging Details:
------------------
FAULTING_THREAD: 83318da8
DEFAULT_BUCKET_ID: GRAPHICS_DRIVER_FAULT
CUSTOMER_CRASH_COUNT: 5
BUGCHECK_STR: 0xEA
PROCESS_NAME: opera.exe
LAST_CONTROL_TRANSFER: from 804e39ce to 804db7f3
STACK_TEXT:
b95bd9a4 804e39ce f7a99b40 f7a99b70 00000000 nt!KiUnlockDispatcherDatabase+0x77
b95bd9b8 f7946a67 f7a99b94 00000000 00000000 nt!KeSetEvent+0x74
b95bdcac 804ecaaa f7a99b40 b95bdcf8 b95bdcec watchdog!WatchdogKernelApc+0x13b
b95bdcfc 806f0c35 00000000 00000000 b95bdd14 nt!KiDeliverApc+0xb3
b95bdcfc 804d90ac 00000000 00000000 b95bdd14 hal!HalpApcInterrupt+0xc5
b95bdd84 f686bd24 f575d720 836e0400 f688af4f nt!READ_REGISTER_ULONG+0x6
WARNING: Stack unwind information not available. Following frames may be wrong.
b95bdd8c 836e0400 f688af4f 836e6320 836e0400 nv4_mini+0x5bd24
b95bdd90 f688af4f 836e6320 836e0400 00400720 0x836e0400
b95bdd94 836e6320 836e0400 00400720 83714788 nv4_mini+0x7af4f
b95bdd98 836e0400 00400720 83714788 836e0400 0x836e6320
b95bdd9c 00400720 83714788 836e0400 b95bde20 0x836e0400
b95bdda0 83714788 836e0400 b95bde20 b95bde20 0x400720
b95bdda4 836e0400 b95bde20 b95bde20 f69ddb5c 0x83714788
b95bdda8 b95bde20 b95bde20 f69ddb5c 00000000 0x836e0400
b95bddac b95bde20 f69ddb5c 00000000 00400720 0xb95bde20
b95bde20 11a9828c 00000028 03260088 00000011 0xb95bde20
b95bde24 00000000 03260088 00000011 00000000 0x11a9828c
STACK_COMMAND: .thread 0xffffffff83318da8 ; kb
FOLLOWUP_IP:
nv4_mini+5bd24
f686bd24 ?? ???
SYMBOL_STACK_INDEX: 6
SYMBOL_NAME: nv4_mini+5bd24
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: nv4_mini
IMAGE_NAME: nv4_mini.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 453bddb2
FAILURE_BUCKET_ID: 0xEA_IMAGE_nv4_mini.sys_DATE_2006_10_22
BUCKET_ID: 0xEA_IMAGE_nv4_mini.sys_DATE_2006_10_22
Followup: MachineOwner
---------
Prosze o pomoc !
z tym, że mi udało się (mam nadzieję) znaleźć rozwiązanie. Otóż mam ten sam model płyty, aczkolwiek inne podzespoły (dysk grafikę) też miałem resety w trakcie instalacji programów, albo po 20-30 minutach kiedy komputer nic nie robił, był tylko włączony.... Też zmieniałem kości, zasilanie, dysk, nawet LAN wpiąłem inny. Zero poprawy. Resety dalej były. Nawet pastę pod radiatorem na procku zmieniałem na nową i nic to nie dało. Szukałem spuchniętych kondensatorów na płycie głównej, bo i z tym miałem kiedyś do czynienia - wszystkie jednak były dobre...