BSOD - dodatkowy dysk, a może karta graficzna ?

Post06 mar 2012, 08:34

Reinstalacja wszystkich sterowników od każdego urządzenia, nawet myszki i karty sieciowej. Zmiana zabezpieczeń na inny antywirus i firewall (testowo aby sprawdzić czy coś to daje), bo programy te mogą zbyt mocno ingerować w system powodując konflikty.

Post06 mar 2012, 19:47

Wychodzi na jedno, więc zrobiłem formata. Nie korzystam już z karty graficznej PCI-E i BSODów póki co brak.

Można jakoś sprawdzić, co z kartą było nie tak? Na początku nie było błędów - kupiłem ją używaną i problemy zaczęły się pojawiać po ok 3 miesiącach. Jest to ATI Radeon HD 5670.

Post07 mar 2012, 08:44

Tylko organoleptycznie, czyli na oczy, zobaczyć czy dobrze siedzi dodatkowe zasilanie, a także benchmarki i w nich sprawdzanie pod obciążeniem. Jako takich testów dostępnych publicznie to nie ma.

Post13 mar 2012, 17:20

Hm, bez karty zewnętrznej również wyskoczył BSOD, tym razem związany z pamięcią:

Kod: Zaznacz cały

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


Loading Dump File [C:\Windows\Minidump\030712-30810-01.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 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02c61000 PsLoadedModuleList = 0xfffff800`02ea6670
Debug session time: Wed Mar  7 14:36:12.250 2012 (GMT+1)
System Uptime: 0 days 0:54:05.827
Loading Kernel Symbols
...............................................................
................................................................
.....................
Loading User Symbols
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1A, {41287, 6355d, 0, 0}

Probably caused by : ntkrnlmp.exe ( nt! ?? ::FNODOBFM::`string'+46485 )

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

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

MEMORY_MANAGEMENT (1a)
    # Any other values for parameter 1 must be individually examined.
Arguments:
Arg1: 0000000000041287, The subtype of the bugcheck.
Arg2: 000000000006355d
Arg3: 0000000000000000
Arg4: 0000000000000000

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


BUGCHECK_STR:  0x1a_41287

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  VSSVC.exe

CURRENT_IRQL:  0

TRAP_FRAME:  fffff88006dc1160 -- (.trap 0xfffff88006dc1160)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffa80039c24a0 rbx=0000000000000000 rcx=0000000000000000
rdx=fffff98011ba9000 rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002fda687 rsp=fffff88006dc12f0 rbp=fffff88006dc1710
 r8=000000000000000f  r9=0000000001fe9000 r10=0000000000000000
r11=0000000000000001 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei ng nz ac po cy
nt!CcMapData+0x117:
fffff800`02fda687 0fb602          movzx   eax,byte ptr [rdx] ds:fffff980`11ba9000=??
Resetting default scope

LAST_CONTROL_TRANSFER:  from fffff80002c70d7e to fffff80002cddc40

STACK_TEXT:  
fffff880`06dc0ba8 fffff800`02c70d7e : 00000000`0000001a 00000000`00041287 00000000`0006355d 00000000`00000000 : nt!KeBugCheckEx
fffff880`06dc0bb0 fffff800`02cdbd6e : 00000000`00000000 00000000`0006355d 00000000`00000000 00000000`00003160 : nt! ?? ::FNODOBFM::`string'+0x46485
fffff880`06dc0d10 fffff800`02cfce0a : fffffa80`04d76f80 fffffa80`00000001 fffffa80`0404a470 fffffa80`01500870 : nt!KiPageFault+0x16e
fffff880`06dc0ea0 fffff800`02d0574d : fffffa80`04d76e90 00000000`00000000 fffff800`02f13ac0 fffffa80`04d76e90 : nt!MiCompleteProtoPteFault+0x28a
fffff880`06dc0f30 fffff800`02cebf59 : 00000000`00000000 00000000`00000000 ffffffff`ffffffff fffff800`02ceaf98 : nt!MiIssueHardFault+0x309
fffff880`06dc1000 fffff800`02cdbd6e : 00000000`00000000 fffff980`11ba9000 fffff880`06dc1200 00000000`0000000e : nt!MmAccessFault+0x1399
fffff880`06dc1160 fffff800`02fda687 : 00000000`00000001 00000000`0bfe9000 fffff880`06dc13b8 fffff880`06dc13b0 : nt!KiPageFault+0x16e
fffff880`06dc12f0 fffff880`013071e2 : fffff8a0`00017000 fffffa80`039c24a0 fffff8a0`085e3246 fffff8a0`0000000e : nt!CcMapData+0x117
fffff880`06dc13b0 fffff880`012f3c1f : fffffa80`03fe6720 fffffa80`03c2c180 fffff8a0`0adcb7d0 00000000`00000000 : Ntfs!NtfsReadMftRecord+0xb2
fffff880`06dc1460 fffff880`012efab8 : fffffa80`03fe6720 fffff8a0`071d2390 fffff8a0`071d2140 fffffa80`03fe6701 : Ntfs!NtfsRetrieveOtherFileName+0x2e3
fffff880`06dc1590 fffff880`012f0ff1 : fffff880`06dc1a90 00000000`00000000 fffffa80`0524b200 fffffa80`05cce3a0 : Ntfs!NtfsQueryDirectory+0xa38
fffff880`06dc1930 fffff880`012f38ef : fffffa80`03fe6720 00000000`00000000 fffff880`06dc1a20 00000000`00000000 : Ntfs!NtfsCommonDirectoryControl+0xa1
fffff880`06dc1970 fffff880`01185bcf : fffffa80`05cce740 fffffa80`05cce3a0 fffffa80`03fe6720 fffff880`06dc1998 : Ntfs!NtfsFsdDirectoryControl+0x10f
fffff880`06dc19e0 fffff880`011846df : fffffa80`0524b200 fffffa80`05dc4f20 fffffa80`0524b200 fffffa80`05cce3a0 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x24f
fffff880`06dc1a70 fffff800`02fc740d : fffffa80`05cce3a0 fffff880`06dc1ca0 00000000`012ebbf8 fffff880`06dc1bc8 : fltmgr!FltpDispatch+0xcf
fffff880`06dc1ad0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!NtQueryDirectoryFile+0x1ad


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt! ?? ::FNODOBFM::`string'+46485
fffff800`02c70d7e cc              int     3

SYMBOL_STACK_INDEX:  1

SYMBOL_NAME:  nt! ?? ::FNODOBFM::`string'+46485

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

FAILURE_BUCKET_ID:  X64_0x1a_41287_nt!_??_::FNODOBFM::_string_+46485

BUCKET_ID:  X64_0x1a_41287_nt!_??_::FNODOBFM::_string_+46485

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

Dwie z dwóch kości pamięci oddzielnie przeszły 2 pełne testy Memtest bez błędów. Ale nie wiem czemu Memtest wyświetlał, że kość ma 1GB, podczas gdy ma 2GB (komplet 2x 2GB = 4GB DUAL KINGSTON). Ograniczenie Memtesta czy jak?

Wracając do kart graficznych - trochę posprawdzałem i wychodzi na to, że przy dwóch kartach graficznych zewnętrznych pojawiają się błędy - rozumiem że coś jest nie tak albo z obiema kartami PCI-E albo MB.

Tutaj 2 BSOD'y związane z testowaniem kart zewnętrznych (po formacie):

Kod: Zaznacz cały

Loading Dump File [C:\Windows\Minidump\030712-26925-01.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 7 Kernel Version 7601 (Service Pack 1) MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17640.amd64fre.win7sp1_gdr.110622-1506
Machine Name:
Kernel base = 0xfffff800`02c1a000 PsLoadedModuleList = 0xfffff800`02e5f670
Debug session time: Wed Mar  7 13:07:26.394 2012 (GMT+1)
System Uptime: 0 days 0:00:28.596
Loading Kernel Symbols
...............................................................
..............................................................
Loading User Symbols
Loading unloaded module list
....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 7F, {8, 80050031, 6f8, fffff80002c99572}

Probably caused by : ntkrnlmp.exe ( nt!KiDoubleFaultAbort+b2 )

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

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

UNEXPECTED_KERNEL_MODE_TRAP (7f)
This means a trap occurred in kernel mode, and it's a trap of a kind
that the kernel isn't allowed to have/catch (bound trap) or that
is always instant death (double fault).  The first number in the
bugcheck params is the number of the trap (8 = double fault, etc)
Consult an Intel x86 family manual to learn more about what these
traps are. Here is a *portion* of those codes:
If kv shows a taskGate
        use .tss on the part before the colon, then kv.
Else if kv shows a trapframe
        use .trap on that value
Else
        .trap on the appropriate frame will show where the trap was taken
        (on x86, this will be the ebp that goes with the procedure KiTrap)
Endif
kb will then show the corrected stack.
Arguments:
Arg1: 0000000000000008, EXCEPTION_DOUBLE_FAULT
Arg2: 0000000080050031
Arg3: 00000000000006f8
Arg4: fffff80002c99572

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


BUGCHECK_STR:  0x7f_8

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

PROCESS_NAME:  csrss.exe

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff80002c961e9 to fffff80002c96c40

STACK_TEXT:  
fffff880`031dbce8 fffff800`02c961e9 : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx
fffff880`031dbcf0 fffff800`02c946b2 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x69
fffff880`031dbe30 fffff800`02c99572 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb2
fffff800`009b0fb0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchInterrupt+0x32


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiDoubleFaultAbort+b2
fffff800`02c946b2 90              nop

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  nt!KiDoubleFaultAbort+b2

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  4e02aaa3

FAILURE_BUCKET_ID:  X64_0x7f_8_nt!KiDoubleFaultAbort+b2

BUCKET_ID:  X64_0x7f_8_nt!KiDoubleFaultAbort+b2

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

Kod: Zaznacz cały

Loading Dump File [C:\Windows\Minidump\030612-24273-01.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 7 Kernel Version 7600 MP (4 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7600.16385.amd64fre.win7_rtm.090713-1255
Machine Name:
Kernel base = 0xfffff800`02649000 PsLoadedModuleList = 0xfffff800`02886e50
Debug session time: Tue Mar  6 13:31:13.148 2012 (GMT+1)
System Uptime: 0 days 0:00:06.553
Loading Kernel Symbols
................................................
Loading User Symbols
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 24, {1904fb, fffff880009a7d58, fffff880009a75b0, fffff880010c51f8}

Probably caused by : Ntfs.sys ( Ntfs!NtfsContinueIndexEnumeration+108 )

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

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

NTFS_FILE_SYSTEM (24)
    If you see NtfsExceptionFilter on the stack then the 2nd and 3rd
    parameters are the exception record and context record. Do a .cxr
    on the 3rd parameter and then kb to obtain a more informative stack
    trace.
Arguments:
Arg1: 00000000001904fb
Arg2: fffff880009a7d58
Arg3: fffff880009a75b0
Arg4: fffff880010c51f8

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


EXCEPTION_RECORD:  fffff880009a7d58 -- (.exr 0xfffff880009a7d58)
ExceptionAddress: fffff880010c51f8 (Ntfs!NtfsContinueIndexEnumeration+0x0000000000000108)
   ExceptionCode: c0000005 (Access violation)
  ExceptionFlags: 00000000
NumberParameters: 2
   Parameter[0]: 0000000000000000
   Parameter[1]: 0000000000000017
Attempt to read from address 0000000000000017

CONTEXT:  fffff880009a75b0 -- (.cxr 0xfffff880009a75b0)
rax=ffffffffffffffff rbx=0000000000000000 rcx=fffff880002786c0
rdx=0000000000000054 rsi=0000000000000001 rdi=0000000000000001
rip=fffff880010c51f8 rsp=fffff880009a7f90 rbp=fffff880009a84e0
 r8=fffff98001846092  r9=0000000000000008 r10=0000000000000018
r11=0000000000000001 r12=fffff8a00012b390 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na pe nc
cs=0010  ss=0018  ds=002b  es=002b  fs=0053  gs=002b             efl=00010202
Ntfs!NtfsContinueIndexEnumeration+0x108:
fffff880`010c51f8 488b5818        mov     rbx,qword ptr [rax+18h] ds:002b:00000000`00000017=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

CURRENT_IRQL:  0

ERROR_CODE: (NTSTATUS) 0xc0000005 - Instrukcja spod 0x%08lx odwo

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Instrukcja spod 0x%08lx odwo

EXCEPTION_PARAMETER1:  0000000000000000

EXCEPTION_PARAMETER2:  0000000000000017

READ_ADDRESS: GetPointerFromAddress: unable to read from fffff800028f10e0
 0000000000000017 

FOLLOWUP_IP: 
Ntfs!NtfsContinueIndexEnumeration+108
fffff880`010c51f8 488b5818        mov     rbx,qword ptr [rax+18h]

FAULTING_IP: 
Ntfs!NtfsContinueIndexEnumeration+108
fffff880`010c51f8 488b5818        mov     rbx,qword ptr [rax+18h]

BUGCHECK_STR:  0x24

DEFAULT_BUCKET_ID:  NULL_CLASS_PTR_DEREFERENCE

LAST_CONTROL_TRANSFER:  from 0000000000000000 to fffff880010c51f8

STACK_TEXT:  
fffff880`009a7f90 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : Ntfs!NtfsContinueIndexEnumeration+0x108


SYMBOL_STACK_INDEX:  0

SYMBOL_NAME:  Ntfs!NtfsContinueIndexEnumeration+108

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: Ntfs

IMAGE_NAME:  Ntfs.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4a5bc14f

STACK_COMMAND:  .cxr 0xfffff880009a75b0 ; kb

FAILURE_BUCKET_ID:  X64_0x24_Ntfs!NtfsContinueIndexEnumeration+108

BUCKET_ID:  X64_0x24_Ntfs!NtfsContinueIndexEnumeration+108

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

Posiadam aktualną gwarancję zarówno do MB jak i zewn. karty graficznej, jednak sprytnie zaznaczyli w regulaminie, że jeśli nie znajdą błędu to trzeba im zapłacić. A nie wiem, czy w ogóle sprawdzą coś więcej niż ja

.

Cóż czynić

?

-- 13 mar 2012, 18:20 --

Zmiana płyty głównej pozwoliła na bez-BSOD'ową pracę na karcie graficznej PCI-E.

EOT