Wątek zamknięty

[Rozwiązany] Regularne BSoDy - analiza minidumpa (rozwiązany)

 
FeXXer
Wdrażany
Liczba postów: 38
Post: #1
Lightbulb 

Regularne BSoDy - analiza minidumpa (rozwiązany)


E8400
Sparkle GTX 260-216
Audigy 2ZS
4x1GB A-Data 1066MHz
Chieftec 450W

Wszystko chodziło do czasu reinstalacji systemu, po tym fakcie mam regularne BSoD'y za każdym razem, jest to L1E62x64.sys , a przynajmniej tak wyniki z analizy minidumpów, aktualizacje/zmiany sterownika nie pomagają.

Kod:
Loading Dump File [C: \Users\Damian\Desktop\011111-14305-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 (2 procs) Free x64
Product:  WinNt, suite:  TerminalServer SingleUserTS
Built by:  7600.16617.amd64fre.win7_gdr.100618-1621
Machine Name:
Kernel base = 0xfffff800`02a11000 PsLoadedModuleList = 0xfffff800`02c4ee50
Debug session time:  Tue Jan 11 17: 18: 19.651 2011 (UTC + 1: 00)
System Uptime:  0 days 6: 24: 18.103
Loading Kernel Symbols
...............................................................
................................................................
................................
Loading User Symbols
Loading unloaded module list
.................
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck A, {8, 2, 0, fffff80002ff17f7}

Unable to load image \SystemRoot\system32\DRIVERS\L1E62x64.sys, Win32 error 0n2
*** WARNING:  Unable to verify timestamp for L1E62x64.sys
*** ERROR:  Module load completed but symbols could not be loaded for L1E62x64.sys
Probably caused by :  L1E62x64.sys ( L1E62x64+81f3 )

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1:  0000000000000008, memory referenced
Arg2:  0000000000000002, IRQL
Arg3:  0000000000000000, bitfield :
    bit 0 :  value 0 = read operation, 1 = write operation
    bit 3 :  value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4:  fffff80002ff17f7, address which referenced memory

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


READ_ADDRESS:  GetPointerFromAddress:  unable to read from fffff80002cb90e0
0000000000000008

CURRENT_IRQL:   2

FAULTING_IP:  
hal!HalPutScatterGatherList+a7
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8]

CUSTOMER_CRASH_COUNT:   1

DEFAULT_BUCKET_ID:   VISTA_DRIVER_FAULT

BUGCHECK_STR:   0xA

PROCESS_NAME:   System

TRAP_FRAME:   fffff88009e89890 -- (.trap 0xfffff88009e89890)
NOTE:  The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ff17f7 rsp=fffff88009e89a20 rbp=0000000000000e00
r8=0000000000000000  r9=fffffa8008090e00 r10=fffffffffffffffd
r11=000000000000fffb r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
hal!HalPutScatterGatherList+0xa7:
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8] ds: 9610: 00000000`00000008=?
Resetting default scope

LAST_CONTROL_TRANSFER:   from fffff80002a80ca9 to fffff80002a81740

STACK_TEXT:  
fffff880`09e89748 fffff800`02a80ca9 :  00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 :  nt!KeBugCheckEx
fffff880`09e89750 fffff800`02a7f920 :  00000000`00000010 fffffa80`05ab9c78 fffff880`09e898b0 00000000`00000018 :  nt!KiBugCheckDispatch+0x69
fffff880`09e89890 fffff800`02ff17f7 :  fffffa80`05ab9c78 fffffa80`08090e00 00000000`00000058 fffffa80`08090db8 :  nt!KiPageFault+0x260
fffff880`09e89a20 fffff880`014c28a1 :  fffffa80`07067710 fffffa80`05492940 fffffa80`054a3a78 00000000`00000000 :  hal!HalPutScatterGatherList+0xa7
fffff880`09e89a80 fffff880`069cf1f3 :  fffffa80`054a3000 fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 :  ndis!NdisMFreeNetBufferSGList+0x31
fffff880`09e89ac0 fffffa80`054a3000 :  fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 :  L1E62x64+0x81f3
fffff880`09e89ac8 fffffa80`054a3a78 :  fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 :  0xfffffa80`054a3000
fffff880`09e89ad0 fffffa80`05492940 :  fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 :  0xfffffa80`054a3a78
fffff880`09e89ad8 fffffa80`054a3000 :  fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 :  0xfffffa80`05492940
fffff880`09e89ae0 fffffa80`00000002 :  fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 :  0xfffffa80`054a3000
fffff880`09e89ae8 fffff880`069c9034 :  fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 :  0xfffffa80`00000002
fffff880`09e89af0 fffffa80`0549e5a8 :  fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 00000000`05820000 :  L1E62x64+0x2034
fffff880`09e89af8 fffff880`069c9134 :  00000000`00000000 fffff880`09e89bd8 00000000`05820000 00000000`00000000 :  0xfffffa80`0549e5a8
fffff880`09e89b00 00000000`00000000 :  fffff880`09e89bd8 00000000`05820000 00000000`00000000 fffffa80`054a3000 :  L1E62x64+0x2134


STACK_COMMAND:   kb

FOLLOWUP_IP:  
L1E62x64+81f3
fffff880`069cf1f3 ?              ?

SYMBOL_STACK_INDEX:   5

SYMBOL_NAME:   L1E62x64+81f3

FOLLOWUP_NAME:   MachineOwner

MODULE_NAME:  L1E62x64

IMAGE_NAME:   L1E62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:   4bb00bac

FAILURE_BUCKET_ID:   X64_0xA_L1E62x64+81f3

BUCKET_ID:   X64_0xA_L1E62x64+81f3

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1:  0000000000000008, memory referenced
Arg2:  0000000000000002, IRQL
Arg3:  0000000000000000, bitfield :
    bit 0 :  value 0 = read operation, 1 = write operation
    bit 3 :  value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4:  fffff80002ff17f7, address which referenced memory

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


READ_ADDRESS:   0000000000000008

CURRENT_IRQL:   2

FAULTING_IP:  
hal!HalPutScatterGatherList+a7
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8]

CUSTOMER_CRASH_COUNT:   1

DEFAULT_BUCKET_ID:   VISTA_DRIVER_FAULT

BUGCHECK_STR:   0xA

PROCESS_NAME:   System

TRAP_FRAME:   fffff88009e89890 -- (.trap 0xfffff88009e89890)
NOTE:  The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ff17f7 rsp=fffff88009e89a20 rbp=0000000000000e00
r8=0000000000000000  r9=fffffa8008090e00 r10=fffffffffffffffd
r11=000000000000fffb r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
hal!HalPutScatterGatherList+0xa7:
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8] ds: 9610: 00000000`00000008=?
Resetting default scope

LAST_CONTROL_TRANSFER:   from fffff80002a80ca9 to fffff80002a81740

STACK_TEXT:  
fffff880`09e89748 fffff800`02a80ca9 :  00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 :  nt!KeBugCheckEx
fffff880`09e89750 fffff800`02a7f920 :  00000000`00000010 fffffa80`05ab9c78 fffff880`09e898b0 00000000`00000018 :  nt!KiBugCheckDispatch+0x69
fffff880`09e89890 fffff800`02ff17f7 :  fffffa80`05ab9c78 fffffa80`08090e00 00000000`00000058 fffffa80`08090db8 :  nt!KiPageFault+0x260
fffff880`09e89a20 fffff880`014c28a1 :  fffffa80`07067710 fffffa80`05492940 fffffa80`054a3a78 00000000`00000000 :  hal!HalPutScatterGatherList+0xa7
fffff880`09e89a80 fffff880`069cf1f3 :  fffffa80`054a3000 fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 :  ndis!NdisMFreeNetBufferSGList+0x31
fffff880`09e89ac0 fffffa80`054a3000 :  fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 :  L1E62x64+0x81f3
fffff880`09e89ac8 fffffa80`054a3a78 :  fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 :  0xfffffa80`054a3000
fffff880`09e89ad0 fffffa80`05492940 :  fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 :  0xfffffa80`054a3a78
fffff880`09e89ad8 fffffa80`054a3000 :  fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 :  0xfffffa80`05492940
fffff880`09e89ae0 fffffa80`00000002 :  fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 :  0xfffffa80`054a3000
fffff880`09e89ae8 fffff880`069c9034 :  fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 :  0xfffffa80`00000002
fffff880`09e89af0 fffffa80`0549e5a8 :  fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 00000000`05820000 :  L1E62x64+0x2034
fffff880`09e89af8 fffff880`069c9134 :  00000000`00000000 fffff880`09e89bd8 00000000`05820000 00000000`00000000 :  0xfffffa80`0549e5a8
fffff880`09e89b00 00000000`00000000 :  fffff880`09e89bd8 00000000`05820000 00000000`00000000 fffffa80`054a3000 :  L1E62x64+0x2134


STACK_COMMAND:   kb

FOLLOWUP_IP:  
L1E62x64+81f3
fffff880`069cf1f3 ?              ?

SYMBOL_STACK_INDEX:   5

SYMBOL_NAME:   L1E62x64+81f3

FOLLOWUP_NAME:   MachineOwner

MODULE_NAME:  L1E62x64

IMAGE_NAME:   L1E62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:   4bb00bac

FAILURE_BUCKET_ID:   X64_0xA_L1E62x64+81f3

BUCKET_ID:   X64_0xA_L1E62x64+81f3

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1:  0000000000000008, memory referenced
Arg2:  0000000000000002, IRQL
Arg3:  0000000000000000, bitfield :
    bit 0 :  value 0 = read operation, 1 = write operation
    bit 3 :  value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4:  fffff80002ff17f7, address which referenced memory

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


READ_ADDRESS:   0000000000000008

CURRENT_IRQL:   2

FAULTING_IP:  
hal!HalPutScatterGatherList+a7
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8]

CUSTOMER_CRASH_COUNT:   1

DEFAULT_BUCKET_ID:   VISTA_DRIVER_FAULT

BUGCHECK_STR:   0xA

PROCESS_NAME:   System

TRAP_FRAME:   fffff88009e89890 -- (.trap 0xfffff88009e89890)
NOTE:  The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ff17f7 rsp=fffff88009e89a20 rbp=0000000000000e00
r8=0000000000000000  r9=fffffa8008090e00 r10=fffffffffffffffd
r11=000000000000fffb r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
hal!HalPutScatterGatherList+0xa7:
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8] ds: 9610: 00000000`00000008=?
Resetting default scope

LAST_CONTROL_TRANSFER:   from fffff80002a80ca9 to fffff80002a81740

STACK_TEXT:  
fffff880`09e89748 fffff800`02a80ca9 :  00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 :  nt!KeBugCheckEx
fffff880`09e89750 fffff800`02a7f920 :  00000000`00000010 fffffa80`05ab9c78 fffff880`09e898b0 00000000`00000018 :  nt!KiBugCheckDispatch+0x69
fffff880`09e89890 fffff800`02ff17f7 :  fffffa80`05ab9c78 fffffa80`08090e00 00000000`00000058 fffffa80`08090db8 :  nt!KiPageFault+0x260
fffff880`09e89a20 fffff880`014c28a1 :  fffffa80`07067710 fffffa80`05492940 fffffa80`054a3a78 00000000`00000000 :  hal!HalPutScatterGatherList+0xa7
fffff880`09e89a80 fffff880`069cf1f3 :  fffffa80`054a3000 fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 :  ndis!NdisMFreeNetBufferSGList+0x31
fffff880`09e89ac0 fffffa80`054a3000 :  fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 :  L1E62x64+0x81f3
fffff880`09e89ac8 fffffa80`054a3a78 :  fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 :  0xfffffa80`054a3000
fffff880`09e89ad0 fffffa80`05492940 :  fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 :  0xfffffa80`054a3a78
fffff880`09e89ad8 fffffa80`054a3000 :  fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 :  0xfffffa80`05492940
fffff880`09e89ae0 fffffa80`00000002 :  fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 :  0xfffffa80`054a3000
fffff880`09e89ae8 fffff880`069c9034 :  fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 :  0xfffffa80`00000002
fffff880`09e89af0 fffffa80`0549e5a8 :  fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 00000000`05820000 :  L1E62x64+0x2034
fffff880`09e89af8 fffff880`069c9134 :  00000000`00000000 fffff880`09e89bd8 00000000`05820000 00000000`00000000 :  0xfffffa80`0549e5a8
fffff880`09e89b00 00000000`00000000 :  fffff880`09e89bd8 00000000`05820000 00000000`00000000 fffffa80`054a3000 :  L1E62x64+0x2134


STACK_COMMAND:   kb

FOLLOWUP_IP:  
L1E62x64+81f3
fffff880`069cf1f3 ?              ?

SYMBOL_STACK_INDEX:   5

SYMBOL_NAME:   L1E62x64+81f3

FOLLOWUP_NAME:   MachineOwner

MODULE_NAME:  L1E62x64

IMAGE_NAME:   L1E62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:   4bb00bac

FAILURE_BUCKET_ID:   X64_0xA_L1E62x64+81f3

BUCKET_ID:   X64_0xA_L1E62x64+81f3

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1:  0000000000000008, memory referenced
Arg2:  0000000000000002, IRQL
Arg3:  0000000000000000, bitfield :
    bit 0 :  value 0 = read operation, 1 = write operation
    bit 3 :  value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4:  fffff80002ff17f7, address which referenced memory

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


READ_ADDRESS:   0000000000000008

CURRENT_IRQL:   2

FAULTING_IP:  
hal!HalPutScatterGatherList+a7
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8]

CUSTOMER_CRASH_COUNT:   1

DEFAULT_BUCKET_ID:   VISTA_DRIVER_FAULT

BUGCHECK_STR:   0xA

PROCESS_NAME:   System

TRAP_FRAME:   fffff88009e89890 -- (.trap 0xfffff88009e89890)
NOTE:  The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ff17f7 rsp=fffff88009e89a20 rbp=0000000000000e00
r8=0000000000000000  r9=fffffa8008090e00 r10=fffffffffffffffd
r11=000000000000fffb r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
hal!HalPutScatterGatherList+0xa7:
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8] ds: 9610: 00000000`00000008=?
Resetting default scope

LAST_CONTROL_TRANSFER:   from fffff80002a80ca9 to fffff80002a81740

STACK_TEXT:  
fffff880`09e89748 fffff800`02a80ca9 :  00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 :  nt!KeBugCheckEx
fffff880`09e89750 fffff800`02a7f920 :  00000000`00000010 fffffa80`05ab9c78 fffff880`09e898b0 00000000`00000018 :  nt!KiBugCheckDispatch+0x69
fffff880`09e89890 fffff800`02ff17f7 :  fffffa80`05ab9c78 fffffa80`08090e00 00000000`00000058 fffffa80`08090db8 :  nt!KiPageFault+0x260
fffff880`09e89a20 fffff880`014c28a1 :  fffffa80`07067710 fffffa80`05492940 fffffa80`054a3a78 00000000`00000000 :  hal!HalPutScatterGatherList+0xa7
fffff880`09e89a80 fffff880`069cf1f3 :  fffffa80`054a3000 fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 :  ndis!NdisMFreeNetBufferSGList+0x31
fffff880`09e89ac0 fffffa80`054a3000 :  fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 :  L1E62x64+0x81f3
fffff880`09e89ac8 fffffa80`054a3a78 :  fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 :  0xfffffa80`054a3000
fffff880`09e89ad0 fffffa80`05492940 :  fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 :  0xfffffa80`054a3a78
fffff880`09e89ad8 fffffa80`054a3000 :  fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 :  0xfffffa80`05492940
fffff880`09e89ae0 fffffa80`00000002 :  fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 :  0xfffffa80`054a3000
fffff880`09e89ae8 fffff880`069c9034 :  fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 :  0xfffffa80`00000002
fffff880`09e89af0 fffffa80`0549e5a8 :  fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 00000000`05820000 :  L1E62x64+0x2034
fffff880`09e89af8 fffff880`069c9134 :  00000000`00000000 fffff880`09e89bd8 00000000`05820000 00000000`00000000 :  0xfffffa80`0549e5a8
fffff880`09e89b00 00000000`00000000 :  fffff880`09e89bd8 00000000`05820000 00000000`00000000 fffffa80`054a3000 :  L1E62x64+0x2134


STACK_COMMAND:   kb

FOLLOWUP_IP:  
L1E62x64+81f3
fffff880`069cf1f3 ?              ?

SYMBOL_STACK_INDEX:   5

SYMBOL_NAME:   L1E62x64+81f3

FOLLOWUP_NAME:   MachineOwner

MODULE_NAME:  L1E62x64

IMAGE_NAME:   L1E62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:   4bb00bac

FAILURE_BUCKET_ID:   X64_0xA_L1E62x64+81f3

BUCKET_ID:   X64_0xA_L1E62x64+81f3

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1:  0000000000000008, memory referenced
Arg2:  0000000000000002, IRQL
Arg3:  0000000000000000, bitfield :
    bit 0 :  value 0 = read operation, 1 = write operation
    bit 3 :  value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4:  fffff80002ff17f7, address which referenced memory

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


READ_ADDRESS:   0000000000000008

CURRENT_IRQL:   2

FAULTING_IP:  
hal!HalPutScatterGatherList+a7
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8]

CUSTOMER_CRASH_COUNT:   1

DEFAULT_BUCKET_ID:   VISTA_DRIVER_FAULT

BUGCHECK_STR:   0xA

PROCESS_NAME:   System

TRAP_FRAME:   fffff88009e89890 -- (.trap 0xfffff88009e89890)
NOTE:  The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ff17f7 rsp=fffff88009e89a20 rbp=0000000000000e00
r8=0000000000000000  r9=fffffa8008090e00 r10=fffffffffffffffd
r11=000000000000fffb r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
hal!HalPutScatterGatherList+0xa7:
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8] ds: 9610: 00000000`00000008=?
Resetting default scope

LAST_CONTROL_TRANSFER:   from fffff80002a80ca9 to fffff80002a81740

STACK_TEXT:  
fffff880`09e89748 fffff800`02a80ca9 :  00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 :  nt!KeBugCheckEx
fffff880`09e89750 fffff800`02a7f920 :  00000000`00000010 fffffa80`05ab9c78 fffff880`09e898b0 00000000`00000018 :  nt!KiBugCheckDispatch+0x69
fffff880`09e89890 fffff800`02ff17f7 :  fffffa80`05ab9c78 fffffa80`08090e00 00000000`00000058 fffffa80`08090db8 :  nt!KiPageFault+0x260
fffff880`09e89a20 fffff880`014c28a1 :  fffffa80`07067710 fffffa80`05492940 fffffa80`054a3a78 00000000`00000000 :  hal!HalPutScatterGatherList+0xa7
fffff880`09e89a80 fffff880`069cf1f3 :  fffffa80`054a3000 fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 :  ndis!NdisMFreeNetBufferSGList+0x31
fffff880`09e89ac0 fffffa80`054a3000 :  fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 :  L1E62x64+0x81f3
fffff880`09e89ac8 fffffa80`054a3a78 :  fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 :  0xfffffa80`054a3000
fffff880`09e89ad0 fffffa80`05492940 :  fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 :  0xfffffa80`054a3a78
fffff880`09e89ad8 fffffa80`054a3000 :  fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 :  0xfffffa80`05492940
fffff880`09e89ae0 fffffa80`00000002 :  fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 :  0xfffffa80`054a3000
fffff880`09e89ae8 fffff880`069c9034 :  fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 :  0xfffffa80`00000002
fffff880`09e89af0 fffffa80`0549e5a8 :  fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 00000000`05820000 :  L1E62x64+0x2034
fffff880`09e89af8 fffff880`069c9134 :  00000000`00000000 fffff880`09e89bd8 00000000`05820000 00000000`00000000 :  0xfffffa80`0549e5a8
fffff880`09e89b00 00000000`00000000 :  fffff880`09e89bd8 00000000`05820000 00000000`00000000 fffffa80`054a3000 :  L1E62x64+0x2134


STACK_COMMAND:   kb

FOLLOWUP_IP:  
L1E62x64+81f3
fffff880`069cf1f3 ?              ?

SYMBOL_STACK_INDEX:   5

SYMBOL_NAME:   L1E62x64+81f3

FOLLOWUP_NAME:   MachineOwner

MODULE_NAME:  L1E62x64

IMAGE_NAME:   L1E62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:   4bb00bac

FAILURE_BUCKET_ID:   X64_0xA_L1E62x64+81f3

BUCKET_ID:   X64_0xA_L1E62x64+81f3

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

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

IRQL_NOT_LESS_OR_EQUAL (a)
An attempt was made to access a pageable (or completely invalid) address at an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If a kernel debugger is available get the stack backtrace.
Arguments:
Arg1:  0000000000000008, memory referenced
Arg2:  0000000000000002, IRQL
Arg3:  0000000000000000, bitfield :
    bit 0 :  value 0 = read operation, 1 = write operation
    bit 3 :  value 0 = not an execute operation, 1 = execute operation (only on chips which support this level of status)
Arg4:  fffff80002ff17f7, address which referenced memory

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


READ_ADDRESS:   0000000000000008

CURRENT_IRQL:   2

FAULTING_IP:  
hal!HalPutScatterGatherList+a7
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8]

CUSTOMER_CRASH_COUNT:   1

DEFAULT_BUCKET_ID:   VISTA_DRIVER_FAULT

BUGCHECK_STR:   0xA

PROCESS_NAME:   System

TRAP_FRAME:   fffff88009e89890 -- (.trap 0xfffff88009e89890)
NOTE:  The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000001
rdx=0000000000000fff rsi=0000000000000000 rdi=0000000000000000
rip=fffff80002ff17f7 rsp=fffff88009e89a20 rbp=0000000000000e00
r8=0000000000000000  r9=fffffa8008090e00 r10=fffffffffffffffd
r11=000000000000fffb r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl zr na po nc
hal!HalPutScatterGatherList+0xa7:
fffff800`02ff17f7 4d8b642408      mov     r12,qword ptr [r12+8] ds: 9610: 00000000`00000008=?
Resetting default scope

LAST_CONTROL_TRANSFER:   from fffff80002a80ca9 to fffff80002a81740

STACK_TEXT:  
fffff880`09e89748 fffff800`02a80ca9 :  00000000`0000000a 00000000`00000008 00000000`00000002 00000000`00000000 :  nt!KeBugCheckEx
fffff880`09e89750 fffff800`02a7f920 :  00000000`00000010 fffffa80`05ab9c78 fffff880`09e898b0 00000000`00000018 :  nt!KiBugCheckDispatch+0x69
fffff880`09e89890 fffff800`02ff17f7 :  fffffa80`05ab9c78 fffffa80`08090e00 00000000`00000058 fffffa80`08090db8 :  nt!KiPageFault+0x260
fffff880`09e89a20 fffff880`014c28a1 :  fffffa80`07067710 fffffa80`05492940 fffffa80`054a3a78 00000000`00000000 :  hal!HalPutScatterGatherList+0xa7
fffff880`09e89a80 fffff880`069cf1f3 :  fffffa80`054a3000 fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 :  ndis!NdisMFreeNetBufferSGList+0x31
fffff880`09e89ac0 fffffa80`054a3000 :  fffffa80`054a3a78 fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 :  L1E62x64+0x81f3
fffff880`09e89ac8 fffffa80`054a3a78 :  fffffa80`05492940 fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 :  0xfffffa80`054a3000
fffff880`09e89ad0 fffffa80`05492940 :  fffffa80`054a3000 fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 :  0xfffffa80`054a3a78
fffff880`09e89ad8 fffffa80`054a3000 :  fffffa80`00000002 fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 :  0xfffffa80`05492940
fffff880`09e89ae0 fffffa80`00000002 :  fffff880`069c9034 fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 :  0xfffffa80`054a3000
fffff880`09e89ae8 fffff880`069c9034 :  fffffa80`0549e5a8 fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 :  0xfffffa80`00000002
fffff880`09e89af0 fffffa80`0549e5a8 :  fffff880`069c9134 00000000`00000000 fffff880`09e89bd8 00000000`05820000 :  L1E62x64+0x2034
fffff880`09e89af8 fffff880`069c9134 :  00000000`00000000 fffff880`09e89bd8 00000000`05820000 00000000`00000000 :  0xfffffa80`0549e5a8
fffff880`09e89b00 00000000`00000000 :  fffff880`09e89bd8 00000000`05820000 00000000`00000000 fffffa80`054a3000 :  L1E62x64+0x2134


STACK_COMMAND:   kb

FOLLOWUP_IP:  
L1E62x64+81f3
fffff880`069cf1f3 ?              ?

SYMBOL_STACK_INDEX:   5

SYMBOL_NAME:   L1E62x64+81f3

FOLLOWUP_NAME:   MachineOwner

MODULE_NAME:  L1E62x64

IMAGE_NAME:   L1E62x64.sys

DEBUG_FLR_IMAGE_TIMESTAMP:   4bb00bac

FAILURE_BUCKET_ID:   X64_0xA_L1E62x64+81f3

BUCKET_ID:   X64_0xA_L1E62x64+81f3

Followup:  MachineOwner

11.01.2011 18:04

Znajdź wszystkie posty użytkownika
martin1984r
Młodszy user systemu
Liczba postów: 176
Post: #2

RE: Regularne BSoDy - analiza minidumpa


Z poziomu Menadżera urządzeń bym odinstalował kartę sieciową i uruchomił odnowa system aby znalazło ponownie nowy sprzęt, albo zainstalował sterownik od producenta karty sieciowej, ale również przed tym bym odinstalował obecny.

11.01.2011 19:40

Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #3

RE: Regularne BSoDy - analiza minidumpa


Wątpie czy to pomoże, ale wywaliłem sterownik i i uruchomiłem system tak jak mówisz. Wcześniej instalowałem sterownik ze strony producenta, jest znacznie nowszy od tego z Win7, a BSoDy były. Czekam na rozwój sytuacji.

11.01.2011 23:00

Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #4

RE: Regularne BSoDy - analiza minidumpa


Ciągle BSoD'y

12.01.2011 10:58

Znajdź wszystkie posty użytkownika
bodziulla
VIP

Liczba postów: 2.364
Post: #5

RE: Regularne BSoDy - analiza minidumpa


Hej.
Mogę prosić Ciebie o plik minidump abyś mi przesłał i jeżeli możesz napisz mi jak najdokładniej o Twoim sprzęcie. Pytanie czy Twój system jest w wersji PL?. Dwa skąd masz system i czy jest legal nie torrent czy coś w tym rodzajuCwaniak
Pzdr

Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)

12.01.2011 15:19

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #6

RE: Regularne BSoDy - analiza minidumpa


System Windows 7 Professional PL 64 bit - legit z programu MSDNAA.

E8400
GTX 260
DD2 4x1GB A-Data 1066MHz
Audigy 2 ZS
Asus P5QL PRO
Seagate 7200.12 500GB
Samsung F2 1,5TB
Chieftec 450W

Wszystko instalowane ze strony producenta lub najnowsze sterowniki jakie udało się znaleźć.

Dodam, że na Win7 przesiadłem się jakieś 7 miesięcy temu i wszystko było ok. Parę dni temu formatowałem OS, bo strasznie się zamulił, stwierdziłem, że szybciej pozbędę się problemu poprzez format. Jednak przez to zaczęły pojawiać się BSoDy. Formatowałem 2 lub 3 razy bo myślałem, że coś skopałem, ale zawsze było tak samo.

Oto ostatni minidump (nie mogłem dodać załącznika) http://www.sendspace.pl/file/e6cdf487e7ba812421a708e

Jeśli inne informacje byłyby niezbędne proszę pytać.
(Ten post był ostatnio modyfikowany: 12.01.2011 18:10 przez FeXXer.)

12.01.2011 18:05

Znajdź wszystkie posty użytkownika
bodziulla
VIP

Liczba postów: 2.364
Post: #7

RE: Regularne BSoDy - analiza minidumpa


Hej.
Jeszcze jedno pytanie jaki masz program antykoncepcyjny na swoim kompie. Twój problem jest dość złożony i masz przerwanie na stosie. W pewnym momencie przekazuje dane na stos, ale później nie potrafi sobie poradzić. Czy robiłeś może overclocking?. Nie wiem czy znasz program Burn In Test. Jak coś pobierz go i zrób test nim i ustaw w programie na badane podzespoły 100% i zobaczymy czy wtedy coś wykryje.
Na razie takie moje sugestie. Aha podejrzewam, że nie zrobiłes nakładki na system tzn.,że instalowałeś z bootowania płyty?.
Pzdr
Jeszcze jedno pytanie jaki miałeś wcześniej system?. Czy dodawałeś jakieś podzespoły?.

Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
(Ten post był ostatnio modyfikowany: 12.01.2011 21:42 przez bodziulla.)

12.01.2011 21:40

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #8

RE: Regularne BSoDy - analiza minidumpa


Używam Aviry oraz Outposta. Wcześniej Win7 pracował stabilnie przez jakieś 7 miesięcy, gdy przetaktowałem E8400@3600Mhz, bez zmian napięć itd. Bardzo się zdziwiłem, gdy na nowo postawionym systemie, rzucał BSoDami. Instalacje systemu robiłem z płytki bootowalnej (zgranego wcześniej obrazu z MSDNAA).

System mam ciągle ten sam Win7 Pro 64bit PL. Oczywiście była czysta instalacja (format itd.) Od 7 miesiecy nic nie zmieniałem w podzespołach.

Ogólnie jak czytałem w zasobach internetowych to BSoD'y spowodowane sterownikami są dość łatwe do zlikwidowania, chodzi głównie o zmianę sterownika lub usunięcie jakiegoś programu.

Nie myślałem, że może to być spowodowane OC procesora, skoro wcześniej chodził szmat czasu bez żadnego BSod'u, czy choćby nawet się nie zawiesił przez 7 miesięcy!
____________________________________________________________________________________________________​_____________________________

Odpaliłem Burn In Test, przeprowadziłem testy RAM'u i procesora na standardowych taktowaniach no i PASSED.
(Ten post był ostatnio modyfikowany: 13.01.2011 10:51 przez FeXXer.)

13.01.2011 10:01

Znajdź wszystkie posty użytkownika
bodziulla
VIP

Liczba postów: 2.364
Post: #9

RE: Regularne BSoDy - analiza minidumpa


Hej.
Odnośnie zmian w taktowaniu procka może on chodzić jakiś czas i będzie gut, ale potem się zbuntuje i koniec. Moim zdaniem nic nie wskazuje na sterowniki u Ciebie. Masz przerwanie na stosie i nie radzi sobie. Spróbuj ponownie wrócić do ustawień jak poprzednio i powinno pomóc. Również, jeżeli masz passed w Burn In Test czy możesz napisać jaki jest symbol błędu i czego dotyczy?
Pzdr

Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)

13.01.2011 16:10

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #10

RE: Regularne BSoDy - analiza minidumpa


Zmieniłem taktowanie już dnia wczorajszego póki co nic złego się nie dzieje, dziwi mnie tylko fakt, że system nie daje rady na taktowaniu, które nominalnie było prawidłowe dla mojej konfiguracji. Programem sprawdzałem już po zmianach taktowania, więc błędów nie było jeśli o to chodzi. Mam nadzieje, że dobrze zrozumiałem pytanie Uśmiechnięty

13.01.2011 20:36

Znajdź wszystkie posty użytkownika
bodziulla
VIP

Liczba postów: 2.364
Post: #11

RE: Regularne BSoDy - analiza minidumpa


Hej.
Dokładnie o to mi chodziło. Praktycznie uważam, że teraz nie będziesz miał bsoda i dotyczył praktycznie Twojego przetaktowania. Nikt nie zauważył a raczej sugerował się tylko nazwą błędu, ale bsody czyta się całe. Tutaj było ewidentne przerwanie na stosie i nie dotyczyło to sterownika a błędu w systemie. Coś robiłeś na kompie Twój przetaktowany proc albo miał za mało napięcia lub co innego i nie mógł sobie radzić z poleceniem i powodował błędy na stosie a co za tym idzie polecenia, które były wysyłane z mostka S lub N powodowało utratę chwilową "myślową" i sobie nie radził i system kapitulował. Jeżeli mówisz, że teraz nie masz w Burn In Test błedów to świetnie. Poczytaj może na temat Twojego procka i jego możliwości przetaktowania, bo nie każda seria może być w takiej samej wysokości przetaktowana.Cwaniak
Pzdr

Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)
(Ten post był ostatnio modyfikowany: 14.01.2011 09:49 przez bodziulla.)

14.01.2011 09:47

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #12

RE: Regularne BSoDy - analiza minidumpa


Dziękuje, widzę, że masz pojęcie o tym co piszesz Zacieszacz Mój E8400 w rewizji E0 ma ponoć potencjał, a tak jak pisałem bez problemów radził sobie z 3,6GHz bez zmian napięć przy 1,24V na wcześniejszym systemie. Ja niestety pierwszy zacząłem analizować minidumpy jakiś tydzień temu, bo wtedy miałem pierwszego BSoD'a na Win7 Pro 64bit, a wcześniej nie było to potrzebne. Potrafię wyciągnąć tylko dane, które bezpośrednio wskazują na przyczynę problemu poprzez nazwę Zadowolony

____________________________________________________________________________________________________​_____________________________

Jeszcze niebiesko się nie zrobiło Zadowolony

Jeszcze tylko jedno pytanie, czy wiesz może co jest lepszym narzędziem diagnozującym stabilność RAM, czy memtest, czy może oprogramowanie podane przez Ciebie, które przemawia do mnie wygodą Zacieszacz ?
(Ten post był ostatnio modyfikowany: 14.01.2011 12:53 przez FeXXer.)

14.01.2011 12:24

Znajdź wszystkie posty użytkownika
ihatebuffering
VIP

Liczba postów: 4.011
Post: #13

RE: Regularne BSoDy - analiza minidumpa


Polecam obeznanie się z wątkiem:
Testowanie pamięci RAM programem Memtest86+
Czyli po przywróceniu def taktów procka, BSOD ustąpił? Procek ma potencjał podkręcania, ale to nie sam procek jest kluczem do sukcesu. Może masz ustawioną zbyt duża wartość FSB, za duże takty pamięci ram, zasilacz nie utrzymuje napięć, temperatura.
Napisz jak jaką masz płytę główną i jak ustawiłeś FSB, mnożnik procka, taktowanie pamięci i jakie timingi.

14.01.2011 14:16

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #14

RE: Regularne BSoDy - analiza minidumpa


Tak BSoD'y ustały. Pracuje teraz na 3GHz, FSB 333MHz, reszta AUTO Zacieszacz

Płyta to Asus P5QL PRO, więc chyba nie jest źle.

FSB wcześniej było ustawione na 400MHz a mnożnik 9, więc na czysto 3,6GHz, reszta chyba AUTO Zacieszacz Znajomy polecił, abym sprawdził, czy stabilnie będzie przy samej zmianie FSB, ze względu na możliwości procesora i tak właśnie było. Wiem, że na tej płycie mógłbym pewnie dojść do stabilnych 4GHz, przy odrobinie wsparcia i chęci.

Temperatury są na dobrym poziomie, nie przekraczają norm.
E8400 chłodzone SilentiumPC Spartanem, max 57-58*C (OCCT),
GPU Sparkle GTX 260-216core, też ma się dobrze tutaj max w grach to 75*C a furmark jakieś 87-88*C,
pamięci to 4 sztuki DDR2 A-Data Vitesta 1GB 1066MHz,
zasilacz to poczciwy Chieftec (GPS-450A), pamiętający czasy 18-stki Zacieszacz jednak dobrze sobie radził przez ten cały okres i powinien mieć jeszcze mały zapas.

Chętnie bym przetaktował go na 4GHz, tylko potrzebuje małego wsparcia, sam czytając poradniki mam pewne obawy, że coś mogłem zrozumieć inaczej, albo pomylić opcje w BIOS'ie. A nie każda płyta główna oferuje takie same ustawienia w BIOS'ie.

____________________________________________________________________________________________________​___________________________

Dzięki za linka do wątku, przyda się.
(Ten post był ostatnio modyfikowany: 14.01.2011 19:34 przez FeXXer.)

14.01.2011 19:31

Znajdź wszystkie posty użytkownika
bodziulla
VIP

Liczba postów: 2.364
Post: #15

RE: Regularne BSoDy - analiza minidumpa


Hej.
Pobierz sobie program CPU- Z i pokaż na screenie jaki masz model procka?.Zakładka CPU wskaże nam jaki masz model i wtedy można coś powiedzieć jak i na ile można wydolić z Twoim prockiem. Podaj też jaki masz biosCwaniak
Pzdr

Jeżeli uważasz, że pomogłem kliknij POMÓGŁ. Pzdr :)

14.01.2011 21:48

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #16

RE: Regularne BSoDy - analiza minidumpa


To chyba wszystko o co prosiłeś.


Załączone pliki Miniatury
       

14.01.2011 22:17

Znajdź wszystkie posty użytkownika
ihatebuffering
VIP

Liczba postów: 4.011
Post: #17

RE: Regularne BSoDy - analiza minidumpa


No nieźle, zwiększenie FSB i reszta na Auto nie wróżą sukcesu w OC Zadowolony Zwiększając FSB, zwiększają się takty pamięci Ram i timingi też pewnie poszły Ci w górę (większe timingi to gorzej). Musisz wszystko dobrze dopasować. O chłodzenie martwić się nie musisz. Jurto możemy posiedzieć nad OC.

14.01.2011 23:27

Róża Podziękowania od: FeXXer
Znajdź wszystkie posty użytkownika
FeXXer
Wdrażany
Liczba postów: 38
Post: #18

RE: Regularne BSoDy - analiza minidumpa


Może samo zwiększanie FSB nie jest szczególnie zalecane, ale uwierz mi przez ostatnie pół roku, jeszcze przez reinstalem OS, miałem właśnie takie ustawienia, a PC był naprawdę stabilny, nie zanotowałem nawet 1 (słownie: jednego) zawieszenia systemu Zadowolony
Jutro, a w zasadzie już dziś będę miał trochę czasu, także nie ma problemu.

____________________________________________________________________________________________________​_____________________________

Sądzę, że można już bez przeszkód zamknąć wątek, bo zaczyna zmierzać w nieco inną stronę, a cel już został osiągnięty poprzez znalezienie przyczyny opisanego problemu.
(Ten post był ostatnio modyfikowany: 15.01.2011 00:48 przez FeXXer.)

15.01.2011 00:36

Znajdź wszystkie posty użytkownika
Wątek zamknięty

Podobne wątki
Wątek: Autor Odpowiedzi: Wyświetleń: Ostatni post
Niespodziewane BSODy, logi z BlueScreenView do analizy Namess4 9 1.637 11.02.2014 19:50
Ostatni post: thermalfake
Jak naprawić BSODy w trakcie grania w gry? Deathknife 1 1.640 22.08.2012 00:35
Ostatni post: thermalfake
BSoDy - powrót problemu FeXXer 13 1.982 14.02.2011 04:20
Ostatni post: FeXXer
« Starszy wątek | Nowszy wątek »

Temat został oceniony na 0 w skali 1-5 gwiazdek.
Zebrano 0 głosów.