• Wenn Ihr hier einen Thread erstellt, dann erwartet Euch im Beitragformular eine Vorlage mit notwendigen Grundinformationen, durch die Euch die Community schneller helfen kann. Mehr Informationen dazu findet ihr in diesem Thread.

Bluescreens

Habe jetzt nochmals 5-6 Stunden jedes Rammodul getestet, keinerlei Fehler.
Werde morgen mal meine anderen 2 einbauen und dann testen.

Treiberfehler würde allerdings nicht erklären wieso ich diese Crc Fehler beim entpacken von Sachen hatte bzw habe. Die Fehler hatte ich auch schon mit meinem alten Board also wirds wohl nicht an der Kompatibilität liegen denke ich.
 
Zuletzt bearbeitet:
Die CRC Fehler rühren von den Ultra DMA CRC Error Counts. Von denen sind ja genügend bei den SMART Werten verzeichnet.
Ich drücke die Daumen, dass es mit den anderen Riegeln besser klappt.

Öffne mal die Eingabeaufforderung (als Administrator) und gib folgendes ein: "lissvc" (zeigt die Dienste an), dann "disable dmio" (jeweils ohne ""). Dies deaktiviert den dmio-Dienst, der nach dem Checkdisk Befehl zum Bluescreen geführt hat (er müsste also eigentlich im Sysem sein).
 
Zuletzt bearbeitet:
Verifier.exe gestartet und Pc Neustart gemacht. Danach war der Pc extrem langsam und beim Laden der ganzen Programme bekommme ich immer einen Bluescreen mit 0x000000c4. Meine anderen Ramriegel sind auch drin.
 
Die Bluescreens bitte auswerten, bzw. die genaue Stopfehlermeldung posten.
Der C4 BCCode steht nur für den Verifier und reicht alleine daher nicht aus.
 
Fehlercode:
0x000000c4 (0x00000085, 0x89e05ce0, 0x00000010, 0x000000f0)

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_VERIFIER_DETECTED_VIOLATION (c4)
A device driver attempting to corrupt the system has been caught. This is
because the driver was specified in the registry as being suspect (by the
administrator) and the kernel has enabled substantial checking of this driver.
If the driver attempts to corrupt the system, bugchecks 0xC4, 0xC1 and 0xA will
be among the most commonly seen crashes.
Arguments:
Arg1: 00000085, MmMapLockedPages called to map, but the caller hasn't locked down the MDL pages.
Arg2: 89e05ce0, MDL address.
Arg3: 00000010, Number of pages to map.
Arg4: 000000f0, The first page frame number that isn't locked down.

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

*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************
*************************************************************************
*** ***
*** ***
*** Your debugger is not using the correct symbols ***
*** ***
*** In order for this command to work properly, your symbol path ***
*** must point to .pdb files that have full type information. ***
*** ***
*** Certain .pdb files (such as the public OS symbols) do not ***
*** contain the required information. Contact the group that ***
*** provided you with these symbols if you need this command to ***
*** work. ***
*** ***
*** Type referenced: nt!_KPRCB ***
*** ***
*************************************************************************

BUGCHECK_STR: 0xc4_85

CUSTOMER_CRASH_COUNT: 3

DEFAULT_BUCKET_ID: DRIVER_FAULT

LAST_CONTROL_TRANSFER: from 80658ac5 to 804f9f43

STACK_TEXT:
a0306b5c 80658ac5 000000c4 00000085 89e05ce0 nt!KeBugCheckEx+0x1b
a0306b84 80658b1c 89e05d3c 00000001 8a02f928 nt!ViCheckMdlPages+0xbf
a0306ba4 abf561b2 89e05ce0 00000001 898d35d0 nt!VerifierMapLockedPages+0x50
WARNING: Stack unwind information not available. Following frames may be wrong.
a0306bc4 abf56519 8a02f928 898d35d0 8cc1ef00 AODDriver+0x11b2
a0306c1c 804ef19f 00000020 8cc1ef68 806e7428 AODDriver+0x1519
a0306c2c 80658128 8a47f240 806e7410 8cc1ef68 nt!IopfCallDriver+0x31
a0306c50 8057f982 8cc1efd8 8a47f240 8cc1ef68 nt!IovCallDriver+0xa0
a0306c64 805807f7 898d35d0 8cc1ef68 8a47f240 nt!IopSynchronousServiceTail+0x70
a0306d00 80579274 000000fc 00000000 00000000 nt!IopXxxControlFile+0x5c5
a0306d34 8054163c 000000fc 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
a0306d34 7c91e514 000000fc 00000000 00000000 nt!KiFastCallEntry+0xfc
00f3e65c 00000000 00000000 00000000 00000000 0x7c91e514


STACK_COMMAND: kb

FOLLOWUP_IP:
AODDriver+11b2
abf561b2 ?? ???

SYMBOL_STACK_INDEX: 3

SYMBOL_NAME: AODDriver+11b2

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: AODDriver

IMAGE_NAME: AODDriver.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 4a9b6b12

FAILURE_BUCKET_ID: 0xc4_85_AODDriver+11b2

BUCKET_ID: 0xc4_85_AODDriver+11b2

Followup: MachineOwner
---------
 
IMAGE_NAME: AODDriver.sys

Der Treiber gehört zum AMD Overdrive. Deinstalliere das Tool bitte testweise und lasse den Verifier weiterhin laufen.

Your debugger is not using the correct symbols

Überprüfe bitte auch noch einmal, ob der Symbolpfad korrekt (siehe Anleitung) hinterlegt ist.

Edit: Noch mal zu den Speicherspannungen. Ich würde zumindest eine Spannung von 1,9V im Bios anlegen (wenn das für dich in Ordnung ist). Habe einfach schon zu häufig erlebt, dass der RAM mit den spezifischen Einstellungen nicht korrekt läuft, bzw. Probleme macht.
Bzw. lies erst mal mit HW-Monitor aus, wieviel Spannung überhaupt an den RAM anliegt.
 
Zuletzt bearbeitet:
Habe jetzt auf 1.8V gestellt, Programm zeigt bei den Werten allerdings keine Veränderung. Bis auf +V5 wo der Min wert ca. 0.20~ höher ist.
 
Dann bringt der Hardware Monitor mit deinem Board leider keine verlässlichen Daten bezüglich der RAM-Spannung. Wie siehts denn momentan aus? Dein Sys läuft stabil mit dem Verifier?
Sofern keine C4 Bluescreens mehr kommen, kannst du den Verifier wieder abschalten.
 
System lief jetzt ca. 5-8 Std mit Verifier ohne Probleme, und Firefox etc ist bis jetzt auch noch nicht abgestürtzt.

Hätte aber noch 2 fragen:
Wäre es wegen den CRC Fehlern dann nicht besser eine andere Festplatte zu benutzen?

Bezüglich der 2.1V Ramspannung und Phenom 2, halten die diese Spannung dann aus? Wollte mir eventuell demnächst einen hollen.
 
Verifier kannst du dann abschalten. Das Programm erhöht ja nicht die Stabilität, sondern es checkt alle auf dem System installierten Treiber in einem Prüflauf.

Ultra DMA CRC Errors deuten entweder auf ein Kabelproblem oder auf Probleme mit dem Controller hin. Hat sich der Wert seit dem Kabelwechsel nicht erhöht, lag es eindeutig am Kabel. Eine neue Festplatte wird schon deshalb nicht nötig sein. Die CRC Fehler der heruntergeladenen Sachen ist eine Folge des defekten Kabels. Die fehlerhaft abgespeicherten Daten bleiben fehlerhaft. Die musst du halt löschen und neu herunterladen, dann sollten die CRC-Fehler auch nicht mehr auftreten.

Die Phenom II halten, nach meiner Info, 2,3V RAM-Spannung aus. Die 2,1V deiner RAM sollten daher kein Problem sein. Allerdings läuft ja im Moment alles gut. Die RAM-Spannung steht noch fix auf 1,8V? Insofern wären 2,1V auch gar nicht notwendig.
 
Die Rams laufen noch auf 1.8V. Wollte nur mal wissen obs da mit den neueren CPUs auch solche Probleme mit den Spannungen gibt.

Im Moment läuft ja alles. Also erstmal Danke für die Hilfe.
 
Zurück