To forskjellige BSOD på 10 minutter (Oppe i 6 forskjellige nå)

[AndyG]

Jeg testet brikkene to og to med memtest. Lot de riktignok ikke stå over natten, men to og to fikk de ingen feil, men 2 pass hver. Er det altfor kort tid til å være "gyldig"? Kjører med 4 brikker, 4x1024MB. Disse er manuelt stilt inn i bios på 2.1V og 4-4-4-12. Det er spesifikasjonene til minnet, og dersom alt står på auto får jeg helt andre verdier og BSOD. Det fant jeg ut når maskina var ny.

 

Prøvde å tilbakestille overklokkingen av FSB, fra 3.0GHz tilbake til 2.4GHz. Jeg har så langt ikke hatt noen BSOD etter én dag. Noe småspilling, ellers ikke noe tungt. Har fått høre av CPU kan trenge noe høyere volt, ellers vil det slå ut som alt mulig rart. CPU volt stod på Auto i BIOS. Kan det ha noe å si? Vurderer å prøve å sette tilbake FSB til 3.0GHz og øke volt til cpu bittelitt. Er det reelt at det kan være årsaken? Er CPU volt farlige saker å tukle med?

[Malvado]

Nei, Cpu volt er ikke farlig å tukle med så lenge man vet hva man holder på med...

Dvs, en Core Duo E6300 har standard instillinger 1.325 I volt, å øke da gradvis oppover til 1.4 er null problem så lenge du har riktig kjøleløsning og passer på at temperaturene ikke øker for høyt.

 

Men i disse varme sommermånedene så har jeg selv klokket ned fra 3.0Ghz til 2.4Ghz da dette er langt bedre for cpu

 

Og når det gjelder minnet så la dem stå over natten, Nforce hovedkort er spesielt sære på minnet så det kan være lurt å se om det går bra. Det jeg tror kan gå bra er at du slenger inn alle 4 brikkene og slakker et hakk på timings til 5-5-5-15

[AndyG]

Den siste måneden har jeg ikke hatt en eneste BSOD, før idag. Dette skjedde idag, mens jeg ikke brukte maskinen. Jeg tror uTorrent kjørte, men that's it. Denne gangen var meldingen EXCEPTION_DOUBLE_FAULT. En bugcheck nevner prosesnavn SearchIndexer.e og imagenavn ntkrnlmp.exe. Såvidt jeg har forstått skyldes denne feilen programvarefeil og noe såkalt kernel-overrun; gudene vet hva det er forno. Er det på tide med formatering og reinstallering?

 

Fullstendig kopi av bugcheck ligger i spoiler.

 

 

Microsoft ® Windows Debugger Version 6.9.0003.113 AMD64

Copyright © Microsoft Corporation. All rights reserved.

 

 

Loading Dump File [C:\Windows\Minidump\Mini082208-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: srv*c:\symbols*http://msdl.microsoft.com/download/symbols

Windows Server 2008 Kernel Version 6001 (Service Pack 1) MP (2 procs) Free x64

Product: WinNt, suite: TerminalServer SingleUserTS

Built by: 6001.18063.amd64fre.vistasp1_gdr.080425-1930

Kernel base = 0xfffff800`0205d000 PsLoadedModuleList = 0xfffff800`02222db0

Debug session time: Fri Aug 22 01:40:18.496 2008 (GMT+2)

System Uptime: 0 days 8:09:40.149

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, fffff800020b0d28}

 

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

 

Followup: MachineOwner

---------

 

1: 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: fffff800020b0d28

 

Debugging Details:

------------------

 

 

BUGCHECK_STR: 0x7f_8

 

CUSTOMER_CRASH_COUNT: 1

 

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

 

PROCESS_NAME: SearchIndexer.e

 

CURRENT_IRQL: 0

 

LAST_CONTROL_TRANSFER: from fffff800020b212e to fffff800020b2390

 

STACK_TEXT:

fffffa60`005eaa68 fffff800`020b212e : 00000000`0000007f 00000000`00000008 00000000`80050031 00000000`000006f8 : nt!KeBugCheckEx

fffffa60`005eaa70 fffff800`020b0978 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiBugCheckDispatch+0x6e

fffffa60`005eabb0 fffff800`020b0d28 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDoubleFaultAbort+0xb8

fffffa60`13c29ff0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiGeneralProtectionFault+0x28

 

 

STACK_COMMAND: kb

 

FOLLOWUP_IP:

nt!KiDoubleFaultAbort+b8

fffff800`020b0978 90 nop

 

SYMBOL_STACK_INDEX: 2

 

SYMBOL_NAME: nt!KiDoubleFaultAbort+b8

 

FOLLOWUP_NAME: MachineOwner

 

MODULE_NAME: nt

 

IMAGE_NAME: ntkrnlmp.exe

 

DEBUG_FLR_IMAGE_TIMESTAMP: 4812c3f7

 

FAILURE_BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8

 

BUCKET_ID: X64_0x7f_8_nt!KiDoubleFaultAbort+b8

 

Followup: MachineOwner

---------