Ständige BSOD-Fehler im neuen AMD-System - storeahci.sys

Eine Samsung HD103UJ werkelt da noch?

Die sollte man mal abklemmen, für immer.
 
  • Gefällt mir
Reaktionen: Terrier und BFF
Gunhawk schrieb:
Da zeigt er sogar mehr an - so um die 156W!
Im Windows selbst ohne viel Last schwankt es auch: 141, 102, 216, 129. 105, 98
Wie gesagt, dann stimmt hier wahrscheinlich etwas nicht - ganz gewaltig nicht.
Welches Messgerät?
 
Hast du noch Widerrufsrecht? Falls ja, kauf dir eine Intel CPU!
 
Klar, Intel macht das Leben leichter. :p Toller Tip.
 
  • Gefällt mir
Reaktionen: Buddha1337, Gunhawk und Crazytom
und? Hat das Abstecken der alten HDDs (oder Abschalten der Energiesparoptionen für die Platten) was gebracht oder nicht?
 
Würde mich auch interessieren (inkl der vielen anderen "Ergebnisse").
Aber vielleicht hat der TO ja jetzt endlich die Intel CPU und alles ist gut. :rolleyes:
 
  • Gefällt mir
Reaktionen: pitu
Ich bin heute erst wieder dazu gekommen mich um den PC zu kümmern. Zwischenzeitlich habe ich ein hat ASROCK ein neues BIOS veröffentlicht, welches ich zunächst aufgespielt habe bevor ich weitere Tests mache. Bist jetzt ist noch alles OK.
Die Energieoptionen habe ich vorerst auf den Standards gelassen.
Ergänzung ()

LOL - soeben wieder ein BSOD - am BIOS lag es offenbar nicht. Habe nun testweise die Power-Einstellungen der Festplatten auf Nie gestellt. Den neuesten Dump habe ich mit ins Archiv aufgenommen und angehängt. Ich wette es ist wieder der Storaci.sys, da dies in meinem Zuverlässigkeitsverlauf auch so erwähnt wurde - ach ja - wo sieht man das denn in den Dumps? Sollte der Fehler jetzt nochmal auftreten, werde ich einen letzten Versuch mit einem frisch aufgesetzten Windows machen um Treibereffekte auszuschließen.
Hatte mir den Umstieg zu AMD irgendwie anders vorgestellt.
Danke und Gruß
 

Anhänge

  • 2023-06-05 (1).png
    2023-06-05 (1).png
    21,5 KB · Aufrufe: 115
  • Minidumps.zip
    Minidumps.zip
    4,6 MB · Aufrufe: 113
Zuletzt bearbeitet:
Gunhawk schrieb:
Ich wette es ist wieder der Storaci.sys, … - ach ja - wo sieht man das denn in den Dumps?
Das war doch jetzt schon mehrfach Thema, und du hattest die erste Auswertung mit dem „IMAGE_NAME: storahci.sys“ auch selbst gepostet!
Was sollte sich jetzt daran geändert haben?

Ereignisanzeige? Treiber? Kabel mal gecheckt?
 
Silver Server schrieb:
Du hast die Wette gewonnen.
und wo kann man das nachlesen im Dump? Wenn ich da mit BluescreenView draufschaue, kann ich in der Liste nur zwei rot markierte Einträge "dxgkrnl.sys" und "ntoskrnl.sys" finden - aber ohne Verweis auf Storahci.sys - oder lese ich da falsch?
2023-06-05 (2).png



2023-06-05 (4).png

Ergänzung ()

eYc schrieb:
Das war doch jetzt schon mehrfach Thema, und du hattest die erste Auswertung mit dem „IMAGE_NAME: storahci.sys“ auch selbst gepostet!
Was sollte sich jetzt daran geändert haben?

Ereignisanzeige? Treiber? Kabel mal gecheckt?
Also das heißt im Dump steht das nicht sondern nur in der Ereignisanzeige!?!
 
Gunhawk schrieb:
und wo kann man das nachlesen im Dump?
storahci.PNG

Gunhawk schrieb:
Also das heißt im Dump steht das nicht sondern nur in der Ereignisanzeige!?!
Wenn du nur endlich mal reinsehen würdest, anstatt danach zu fragen. :rolleyes: Unter Windows-Protokolle - System z. b. nach "Quelle = disk, storahci, ..." filtern, könnte so aussehen:
Windows-10-22H2_Ereignisanzeige_disk-storahci_Filter.png Windows-10-22H2_Ereignisanzeige_disk-storahci_Bugcheck_0xef.png
Das war eine defekte SSD, wo's außerdem auch noch zu Bluescreens kam, wie auch unter "Quelle = BugCheck" zu sehen ist. In der EA steht allerdings nur der Fehlercode (hier: 0xef - CRITICAL_PROCESS_DIED), Treiberdateien werden leider nicht genannt. Die SMART-Werte sahen "GUT - 100 %" aus, da war nichts erkennbar.
OCZ-Vertex-2_2_SMART-Werte_CDI_2023-04-03.PNG
Bringt bei SSDs meist nichts, die zu kontrollieren, da keine Mechanik, keine drehenden Plattern, keine Schreib-/Leseköpfe usw.

Was ist denn jetzt mit dem Leerlauf-Verbrauch?
 
Danke für die Infos - im Punkt Leerlauflast zeigt mein Wattmeter so um die 117W an - während ich das hier tippe.
 
Ja das hast du schon geschrieben, die Frage ist aber wo das her kommt, und ob das plausibel ist.
Denn der reine PC kann's nicht sein, wenn nichts übertaktet, overvolted ... ist, und keine Großverbraucher angeschlossen sind.
 
wuselsurfer schrieb:
Hast Du die Samsung HD103UJ abgeklemmt?
Nein die läuft vorerst noch mit. Das Kabel hatte ich gewechselt und der UDMA-Fehlercount ist nicht größer geworden
2023-06-05 (5).png

Ergänzung ()

eYc schrieb:
Ja das hast du schon geschrieben, die Frage ist aber wo das her kommt, und ob das plausibel ist.
Denn der reine PC kann's nicht sein, wenn nichts übertaktet, overvolted ... ist, und keine Großverbraucher angeschlossen sind.
Also angeschlossen sind nur Tastatur, Maus, 3 SATA Platten sowie 2 SATA SSDs und ein SATA Brenner sowie ein NVMe M.2 SSD. Die interne Grafik ist im BIOS abgeschaltet und als GRAKA ist eine RX6600 am werkeln, die normal über PCI angeschlossen ist. Das Mainboard hat natürlich Wifi und BT - das ist natürlich auch an und der Ryzen 7950X sollte auch was ziehen. Das Gehäuse ist ein Fractal Design Define XL mit 3 Gehäuselüftern und der Dark Rock Pro 4 hat ja auch noch zwei Lüfter. Das Netzteil ist ein BeQuite Straight Power 10 %00W Gold 80%
 
Zuletzt bearbeitet:
Gunhawk schrieb:
und wo kann man das nachlesen im Dump? Wenn ich da mit BluescreenView draufschaue, kann ich in der Liste nur zwei rot markierte Einträge "dxgkrnl.sys" und "ntoskrnl.sys" finden - aber ohne Verweis auf Storahci.sys - oder lese ich da falsch?
blue screen View hilft in den allermeisten Fällen nicht weiter.
Zum auswerten der Dumpfile nimmt man das Programm WinDbg.
Hier gibt es eine Anleitung https://www.informationsarchiv.net/articles/2179/
 
Dump sagt wieder, dass die Samsung HDD das Problem ist. Also sichere die Daten auf eine SSD, klemme sie ab und beobachte es die nächsten Tage.
 
Und welche der drei HDs? An welchem Sata port hängt die? Kann man das finden? Habe i, WinDBG das mal gesucht aber irgendwie schaue ich da wohl nicht richtig.
Habe außerdem gelesen das das Board einen der 8 SATA ports mit einem M.2 shared - aber die M.2 ist keine SATA sondern eine NVMe
Ergänzung ()

IDontWantAName schrieb:
laut Dump ist die Samsung HD103SI das Problem. Schalte in den Energieoptionen das Abschalten der Platten auf NIE und schau ob das hilft oder klemme sie mal ab und schaue ob du noch Probleme hast.
Kannst Du mir bitte mal zeigen wo ich das lesen kann. Habe den Dump mit WinDBG angeschaut, aber eine Referenz auf die bestimmte Platte so leider nicht gefunden - schaue aber nochmal nach
 
Zuletzt bearbeitet:
Gunhawk schrieb:
Kannst Du mir bitte mal zeigen wo ich das lesen kann. Habe den Dump mit WinDBG angeschaut, aber eine Referenz auf die bestimmte Platte so leider nicht gefunden - schaue aber nochmal nach

ich zeige mir das mit !devstack SPEICHERADRESSE von Parameter 2 wie in der Doku beschrieben.


DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an IRP for too long a time
Arg2: ffff800f631e0050, Physical Device Object of the stack
14: kd> !devstack ffff800f631e0050
!DevObj !DrvObj !DevExt ObjectName
ffff800f650bb9a0 \Driver\partmgr ffff800f650bbaf0 InfoMask field not found for _OBJECT_HEADER at ffff800f650bb970

ffff800f6541a050 \Driver\disk ffff800f6541a1a0 InfoMask field not found for _OBJECT_HEADER at ffff800f6541a020

> ffff800f631e0050 \Driver\storahci ffff800f631e01a0 Cannot read info offset from nt!ObpInfoMaskToOffset

!DevNode ffff800f631d18a0 :
DeviceInst is "SCSI\Disk&Ven_SAMSUNG&Prod_HD103SI
\7&2a9b7bbb&0&010000"
ServiceName is "disk"

Hier steht jedes mal die Samsung Platte als Ursache. Also nimm sie ganz raus aus dem System.
 
  • Gefällt mir
Reaktionen: Araska, BFF, Terrier und 2 andere
Zurück
Oben