Regelmäßiger Bluescreen!

Also ich werde morgen das alles mal testen..
Der Speicher steht auf auto also wie es halt im bios ist ich habe nichts geändert außer die Lüftersteuerung!
Kann es auch der Steckplatz sein? Ich hab das Ram nämlich einfach in den Slot gesteckt, der am weitesten von der Cpu entfernt ist wegen Temperatur...??
Stecker sitzen!
Ergänzung ()

Hier noch die screens!
 

Anhänge

  • cpu.JPG
    cpu.JPG
    55,1 KB · Aufrufe: 100
  • cpu2.JPG
    cpu2.JPG
    43,3 KB · Aufrufe: 123
  • cpu3.JPG
    cpu3.JPG
    42,9 KB · Aufrufe: 124
  • cpu4.JPG
    cpu4.JPG
    51,3 KB · Aufrufe: 117
Zuletzt bearbeitet:
Stelle den RAM im Bios manuell auf 9-9-9-24-34 ein. Command Rate manuell auf 2T (nicht auf AUTO lassen).

Die aktuell eingestellten Timings sind problematisch, da der Subtiming Wert tRC mit 34clocks bei den Haupttimings 9-12-12-30 zu niedrig ist.

Da der RAM laut SPD Profil auf 9-9-9-24-34 @ 666mhz spezifiziert ist, würde ich diese Timings manuell eintragen. Alternativ kannst du die 9-12-12-30 lassen, dann aber den tRC Wert auf mind. 42clocks anheben (die 9-9-9-24-34 würde ich aber als erstes ausprobieren).

Sollte das System damit nicht stabil laufen, erhöhe die RAM Spannung schrittweise bis max. 1,65V.
 
Kann jemand bestätigen, ob dass Sinn macht?
Ich will dir nicht unterstellen, dass du nicht weisst was du tust vor allem hast du seit 2009 fast 12.000 Beiträge verfasst aber ich fände es doch ganz nett wenn jemand das bestätigen könnte! (habe da nicht den Durchblick)
Falls nicht werde ich dir einfach mal vertrauen! :)
 
12.000 Beiträge sagen nicht aus, ob jemand Ahnung hat ;)
Gesundes Misstrauen ist vollkommen in Ordnung.

----
In dem Link in meiner Signatur (Speicherkompatibilitätsliste) findest du (unter "Ergänzung") Aussagen über die max. RAM Spannung (insbes. in dem verlinkten Datenblatt von AMD Angaben über die max. RAM Spannung für den Memory Controller der CPU, die auf max. 1,65V spezifiziert ist).
Hier findest du etwas über die angesprochenen Timings: http://de.wikipedia.org/wiki/Datei:DRAM_Timings_tRAS_tRP_tRC.png
 
Zuletzt bearbeitet:
Also ich habe jetzt Memtest bis 100% einmal durchlaufen lassen...
-> Keine Fehler
Komisch war aber, dass er konstant 25 Prozent Prozessorauslast hatte also als würde er nur ein Kern verwenden aber alle Kerne wurden angezapft...
Naja egal das ist ein anderes Thema

Ich werde jetzt die Timings ändern ich hoffe damit ist der Bluescreen gestorben!
Ergänzung ()

So habe jetzt die Timings geändert!
Ich hoffe richtig.. kann das bitte jemand kontorllieren?
 

Anhänge

  • IMG_2416.jpg
    IMG_2416.jpg
    252,4 KB · Aufrufe: 97
Sieht gut aus.

Die Memtest Prüfung solltest du allerdings länger laufen lassen (mind. 3-4 Std.). Ebenso sollte die Prüfung nicht innerhalb von Windows ausgeführt werden.
Hierzu empfiehlt es sich die USB Key Version herunter zu laden, auf einen USB Stick einzurichten (Programm entpacken und starten) und über den USB Stick anschließend zu booten.
 
Naja Memtest hat fast 4 Stunden für die 100% gebraucht ich glaube von 11 bis um 14 Uhr

Ich werde falls der Bluescreen weiterhin auftritt einfach Memtest nochma außerhalb von Windows laufen lassen!
 
Soeben hatte ich einen neuen Bluescreen!
Die STOP (nummer) war : 0x0...0109
weiß nimmer wie viele nuller das waren!
Was nun?
 
RAM Spannung stufenweise -wie oben beschrieben- erhöhen.

Minidump-Datei mit WinRAR oder WinZIP einpacken und hier im Forum hochladen (damit der Bluescreen ausgewertet werden kann - falls es doch ein Softwareproblem sein sollte, könnte das damit herausgefunden werden). Alternativ selbst auswerten (Anleitung siehe Signatur).
 
BugCheck 109, {a3a039d89906da6f, b3b7465eeb83a9c5, fffff80003a00ef4, 1}
Arg4: 0000000000000001, Modification of a function or .pdata
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK

Soweit es diesen Bugcheck vom 2.Okt. betrifft, bleibt der RAM der Hauptverdächtige.
 
Von Verlauf kann keine Rede sein, das reinste Dürregebiet:

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


Loading Dump File [D:\HELP\Rabter\fuerbluescreenthreatcomputerbase.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`0365e000 PsLoadedModuleList = 0xfffff800`038a3670
Debug session time: Sun Oct 2 14:28:19.565 2011 (UTC + 2:00)
System Uptime: 0 days 3:09:46.012
Loading Kernel Symbols
...............................................................

***
Use !analyze -v to get detailed debugging information.
BugCheck 109, {a3a039d89906da6f, b3b7465eeb83a9c5, fffff80003a00ef4, 1}
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )
Followup: MachineOwner
---------

2: kd> !analyze -v

CRITICAL_STRUCTURE_CORRUPTION (109)
This bugcheck is generated when the kernel detects that critical kernel code or
data have been corrupted. There are generally three causes for a corruption:
1) A driver has inadvertently or deliberately modified critical kernel code
or data. See http://www.microsoft.com/whdc/driver/kernel/64bitPatching.mspx
2) A developer attempted to set a normal kernel breakpoint using a kernel
debugger that was not attached when the system was booted. Normal breakpoints,
"bp", can only be set if the debugger is attached at boot time. Hardware
breakpoints, "ba", can be set at any time.
3) A hardware corruption occurred, e.g. failing RAM holding kernel code or data.
Arguments:
Arg1: a3a039d89906da6f, Reserved
Arg2: b3b7465eeb83a9c5, Reserved
Arg3: fffff80003a00ef4, Failure type dependent information
Arg4: 0000000000000001, Type of corrupted region, can be
0 : A generic data region
1 : Modification of a function or .pdata
2 : A processor IDT
3 : A processor GDT
4 : Type 1 process list corruption
5 : Type 2 process list corruption
6 : Debug routine modification
7 : Critical MSR modification
Debugging Details:
------------------

BUGCHECK_STR: 0x109
DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT
PROCESS_NAME: System
CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff800036dac40

STACK_TEXT:
fffff880`035c45d8 00000000`00000000 : 00000000`00000109 a3a039d8`9906da6f b3b7465e`eb83a9c5 fffff800`03a00ef4 : nt!KeBugCheckEx

STACK_COMMAND: kb
SYMBOL_NAME: ANALYSIS_INCONCLUSIVE
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: Unknown_Module
IMAGE_NAME: Unknown_Image
DEBUG_FLR_IMAGE_TIMESTAMP: 0
BUCKET_ID: BAD_STACK
Followup: MachineOwner
 
Zuletzt bearbeitet von einem Moderator:
Bitte, als txt:

Hatt ich schon über Debug/Modules gemacht, nur schlagartig vergeßen (stirnrunzel).
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben