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

Finde ich trotzdem seltsam - vor allem dass der Fehler mit der zusätzlichen Referenz auf PCI.SYS wieder aufgetreten ist und die Platten anstandslos in meinem Intel-Altsystem liefen. Würde da eher auf einnen Board-Defekt tippen und überlege einen RMA Prozess dafür anzustossen solange ich noch Garantie habe. Werde zuvor noch noch eine neue Installation machen und eventuell die Platte wieder einbauen. Wenn der Fehler damit wieder auftritt werde ich das Board/CPU austauschen lassen und die Austausch-Hardware mit dieser re-testen.
 
Warum du immer wieder auf das Board (CPU) kommst, wundert mich eh.
Wann ist denn schon mal ein Board für so einen Fehler verantwortlich gewesen?

Jede SSD/HDD tagelang einzeln testen und man hat irgendwann die fehlerhafte SSD/HDD gefunden.
Egal, ob die in einem anderen, (eventuell auch älteren) System läuft.

Wenn man na klar immer seine 7-10 Platten eingesteckt haben will und höchstens mal eine ausbaut, dann braucht es hier 5 Seiten und ein neues Board mit CPU,
Ich hätte längst alles an älteren Platten entsorgt! Zur Not auch alle.
 
  • Gefällt mir
Reaktionen: Engaged
Wir drehen uns halt weiter im Kreis, wie schon seit Wochen, wenn einfache Fragen nicht beantwortet, und für die Fehlersuche wichtige Punkte nicht abgehakt werden.

Ich denke, das Problem hätte sich sehr schnell lösen lassen.
 
  • Gefällt mir
Reaktionen: Terrier
warum wird der kübel ned neu aufgesetzt?
nein, ich hab jetzt ned fünf seiten nachgesichtet, ob das schon gemacht wurde.
 
Gunhawk schrieb:
Finde ich trotzdem seltsam - vor allem dass der Fehler mit der zusätzlichen Referenz auf PCI.SYS wieder aufgetreten ist

die dump zeigt wieder Storage Probleme:

Mit !thread Parameter 3 (!thread ffffe08b74356040) zeigt es einen Stack mit Storport Treiber aufrufen:

13: kd> !thread ffffe08b74356040
THREAD ffffe08b74356040 Cid 0004.01dc Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
ffffa10066dac850 SynchronizationEvent
Not impersonating
GetUlongFromAddress: unable to read from fffff8013180bf74
Owning Process ffffe08b74389040 Image: System
Attached Process N/A Image: N/A
fffff78000000000: Unable to get shared data
Wait Start TickCount 640228
Context Switch Count 39918 IdealProcessor: 16 NoStackSwap
ReadMemory error: Cannot get nt!KeMaximumIncrement value.
UserTime 00:00:00.000
KernelTime 00:00:00.000
Win32 Start Address nt!ExpWorkerThread (0xfffff80130eb0b10)
Stack Init ffffa10066dad5f0 Current ffffa10066dac100
Base ffffa10066dae000 Limit ffffa10066da7000 Call 0000000000000000
Priority 15 BasePriority 12 PriorityDecrement 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
ffffa100`66dac140 fffff801`30e398b5 : ffffca01`ce111180 00000000`00000000 ffffe08b`743eb040 ffffca01`ce111180 : nt!KiSwapContext+0x76
ffffa100`66dac280 fffff801`30e37be4 : ffffe08b`74356040 ffffe08b`00000000 00000094`00000020 00000000`00000000 : nt!KiSwapThread+0xae5
ffffa100`66dac3d0 fffff801`30e36f66 : ffffa488`00000000 00000000`00000001 fffff801`00000000 00000000`00000000 : nt!KiCommitThreadWait+0x134
ffffa100`66dac480 fffff801`35f06334 : fffff801`35f78700 00000000`00000000 ffffe08b`9890bed0 ffffe08b`98d02b50 : nt!KeWaitForSingleObject+0x256
ffffa100`66dac820 fffff801`35f0607d : ffffe08b`9874a1a0 ffffa100`66dacb00 ffffa100`66dacb00 ffffe08b`9890c550 : storport!RaSendIrpSynchronous+0x90
ffffa100`66dac880 fffff801`35f05048 : ffffa100`66dacda0 ffffa100`66dacda0 ffffa100`66dacde0 00000000`00000002 : storport!RaidBusEnumeratorIssueSynchronousRequest+0x23d
ffffa100`66dacab0 fffff801`35f04e62 : ffffe08b`9890c550 00000000`00000000 ffffa100`66dacba0 ffffa100`66dacda0 : storport!RaidBusEnumeratorIssueReportLuns+0x70
ffffa100`66dacb00 fffff801`35f06a80 : 00000000`00000000 00000000`00000000 ffffa100`66dacda0 fffff801`30ea6160 : storport!RaidBusEnumeratorGetLunListFromTarget+0x76
ffffa100`66dacb80 fffff801`35f04d6d : 00000000`00000000 00000000`00000000 00000000`00000000 ffffe08b`77dc51a0 : storport!RaidBusEnumeratorGetLunList+0x54
ffffa100`66dacc10 fffff801`35f04ad9 : 00000000`00000000 ffffa100`66dace00 00000000`00000000 00000000`00000000 : storport!RaidAdapterEnumerateBus+0x99
ffffa100`66dacd80 fffff801`35f04858 : ffffe08b`77dc51a0 ffffa100`66dacee0 00000000`00000000 ffffe08b`00000000 : storport!RaidAdapterRescanBus+0xb1
ffffa100`66dace60 fffff801`35f04668 : 00000000`00000001 fffff801`30eec0fb ffffe08b`96443a60 00000000`00000000 : storport!RaidAdapterQueryDeviceRelationsIrp+0x190
ffffa100`66dacf20 fffff801`35ef6a34 : 00000000`00000000 00000000`00000000 ffffe08b`96443a60 ffffe08b`991a83c0 : storport!RaidAdapterPnpIrp+0x144
ffffa100`66dacfc0 fffff801`30e924e5 : ffffe08b`96443a60 ffffa100`66dad120 ffffe08b`77dc5050 ffffe08b`991a8304 : storport!RaDriverPnpIrp+0x94
ffffa100`66dad000 fffff801`31354b82 : ffffe08b`77d28060 ffffe08b`991a83c0 00000000`00000000 00000000`00000000 : nt!IofCallDriver+0x55
ffffa100`66dad040 fffff801`30f0311e : ffffe08b`77d28060 00000000`00000000 ffffe08b`991a83c0 00000000`00000000 : nt!PnpAsynchronousCall+0xe6
ffffa100`66dad080 fffff801`31354a79 : ffffe08b`77d28a20 00000000`00000000 ffffe08b`77d28060 fffff801`30f032c5 : nt!PnpSendIrp+0x9e
ffffa100`66dad0f0 fffff801`313549e0 : ffffe08b`991a83c0 ffffe08b`77d28a48 ffffe08b`77d28a20 ffffa100`66dad2c0 : nt!PnpQueryDeviceRelations+0x51
ffffa100`66dad180 fffff801`31372c1f : ffffe08b`77d28a20 ffffa100`66dad228 ffffe08b`77d28a20 fffff801`31376800 : nt!PipEnumerateDevice+0xc8
ffffa100`66dad1b0 fffff801`313c6996 : ffffe08b`94a8e100 fffff801`30e90b00 ffffa100`66dad2c0 ffffa100`00000002 : nt!PipProcessDevNodeTree+0x187
ffffa100`66dad270 fffff801`30f5497f : 00000001`00000003 ffffe08b`77d28a20 ffffe08b`94a8e100 00000000`00000000 : nt!PiProcessReenumeration+0x92
ffffa100`66dad2c0 fffff801`30eb0c65 : ffffe08b`74356040 ffffe08b`74323a20 fffff801`31949ac0 fffff801`00000000 : nt!PnpDeviceActionWorker+0x27f
ffffa100`66dad380 fffff801`30ed8dc7 : ffffe08b`74356040 00000000`00000a32 ffffe08b`74356040 fffff801`30eb0b10 : nt!ExpWorkerThread+0x155
ffffa100`66dad570 fffff801`310311e4 : ffffca01`ce9d0180 ffffe08b`74356040 fffff801`30ed8d70 48f08b49`e848280f : nt!PspSystemThreadStartup+0x57
ffffa100`66dad5c0 00000000`00000000 : ffffa100`66dae000 ffffa100`66da7000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x34
 
  • Gefällt mir
Reaktionen: Terrier
Terrier schrieb:
Ich hätte längst alles an älteren Platten entsorgt! Zur Not auch alle.
Im Altsystem laufen sie aber doch noch ohne Probleme.
Gunhawk schrieb:
Würde da eher auf einnen Board-Defekt tippen und überlege einen RMA Prozess dafür anzustossen solange ich noch Garantie habe.
Ich dachte das Board wäre neu. RMA kann aber auf jeden Fall nicht schaden. Wo hattest du es gekauft?
 
pitu schrieb:
Im Altsystem laufen sie aber doch noch ohne Probleme.
Was heißt das denn immer?
Dann muss man halt das alte System weiter nutzen.
Nur weil was mit einem alten System alter Hardware und Windows Xp oder Windows 7 läuft, muss es nicht mit Windows 11 und neuer Hardware laufen.
Wenn es klappt ist ja Ok, wenn man Probleme hat und die nicht lösen kann, dann muss man halt alles erneuern.

Was da überhaupt immer in den Protokollen von RAID und AHCI steht, ist mir doch schon ein Rätsel.
Ist überhaupt im BIOS alles richtig eingestellt. AHCI, kein RAID? BIOS Version aktuell?

Ich nutze PCIe NVMe und da gibt es kein AHCI Fehler.
Bevor ich mich herumärgere, kaufe ich halt nur NVMEs.
Man kann na klar auch Board, CPU, Grafikkarte und am besten auch noch die Hersteller wechseln.
 
pitu schrieb:
Im Altsystem laufen sie aber doch noch ohne Probleme.

Ich dachte das Board wäre neu. RMA kann aber auf jeden Fall nicht schaden. Wo hattest du es gekauft?
Mindfactory
 
Und ich tippe jetzt eher auf das hier:
https://forums.tomshardware.com/threads/driver_power_state_failure-9f-bsod.3809299/

Habe es noch nicht so ganz nachvollziehen können, aber der User hat dieselbe Combo aus Mainboard und CPU am Laufen und es ist tatsächlich so ein ASMedia ASM1061 Controller verbaut, der die vier zusätzlichen SATA-Ports speist.
So wie ich es verstanden habe kommen bei dem Board vier SATA-Ports vom X670E Chipset her und die weiteren vier aus eben diesem Controller. Im Handbuch steht dazu sogar der Hinweis, dass aus Performance-Gründen empfohlen wird Sata SSDs an den X670E Chipset-Controller anzuschließen. "To minimize boot time, use AMD SATA ports SATA3_1-4) for your SSDs"

PS: Habe inzwischen auch eine Neuinstallation gemacht. Während des initialen Aufsetzens gab es noch einen BSOD - inzwischen aber nicht mehr und das obwohl ich die HD103SI jetzt wieder drinnen habe.
 
Gunhawk schrieb:
Im Handbuch steht dazu sogar der Hinweis, dass aus Performance-Gründen empfohlen wird Sata SSDs an den X670E Chipset-Controller anzuschließen. "To minimize boot time, use AMD SATA ports SATA3_1-4) for your SSDs"
Das ist dann na klar auch kein Defekt und kein Grund für eine Reklamation.
Das Board ist Ok, Handbuch lesen sollte man nun mal als 1. wenn man Probleme hat.
 
Gunhawk schrieb:
PS: Habe inzwischen auch eine Neuinstallation gemacht. Während des initialen Aufsetzens gab es noch einen BSOD - inzwischen aber nicht mehr und das obwohl ich die HD103SI jetzt wieder drinnen habe.
Unglaublich, wie beratungsresistent manche hier sind ... .
 
  • Gefällt mir
Reaktionen: eYc
Terrier schrieb:
Das ist dann na klar auch kein Defekt und kein Grund für eine Reklamation.
Das Board ist Ok, Handbuch lesen sollte man nun mal als 1. wenn man Probleme hat.
Naja, so gnz klar ist das nicht. Ich finde es schon komisch wenn ein Treiber/Board nicht die Auto-Einstellungen bzgl. Powermangement unterstützt und da Sachen erst aktiv verdreht werden müssen. Sofern der Fehler nicht mehr auftritt ist die Platte aber wohl OK und nicht die Ursache (sondern eher das Symptom gewesen).
Ergänzung ()

wuselsurfer schrieb:
Unglaublich, wie beratungsresistent manche hier sind ... .
Verstehe das Argument nicht - wenns wirklich an den Einstellungen/Treibern liegt, so ist die Platte doch OK und warum sollte die dann raus...

+++Update+++
Die Platten hängen tatsächlich beide an dem X670E Chipset-Controller. Daher werde ich die wieder an den anderen Controller umhängen und den Test wiederholen - meine Vermutung dazu ist, das der BSOD dann wieder auftritt, womit der ASMedia-Controller dann die Ursache wäre (bzw. eventuell der Treiber und/oder die HIPM-Einstellungen).
 
Zuletzt bearbeitet:
Schon seit vier Wochen habe ich nach Chipsatz- und Controllertreibern (speziell für SATA/Storage) gefragt, mehrfach, und darauf hingewiesen, dass es "Alternativen" (und sogar 'nen zusätzlichen Controller von AsMedia) geben könne, da ich genau so etwas befürchtet, und das auch selbst schon erlebt habe. :freak:
 
  • Gefällt mir
Reaktionen: IDontWantAName
Gunhawk schrieb:
Verstehe das Argument nicht - wenns wirklich an den Einstellungen/Treibern liegt, so ist die Platte doch OK und warum sollte die dann raus...
Du hast immer noch nicht verstanden, daß Festplatten Verschleißteile enthalten.
Da ist es auch egal, was irgendwelche Programme sagen.

Nach 15 Jahren ist die HD 103SI mechanisch durch.
Und mir ist der selbe Typ nach 10 Jahren ansatzlos gestorben.
Glücklicherweise mache ich regelmäßig Backups, so daß keine Datenverluste entstanden sind.

Man sollte die Daten auf eine andere Platte sichern und den Oldie austauschen.
Das habe ich Dir mehrfach gesagt, aber anscheinend hast Du das überlesen.

Egal, meine Daten kommen nicht auf solche Platten.
 
  • Gefällt mir
Reaktionen: whats4 und Terrier
Doch, ich verstehe Dein Argument, jedenfalls sofern die Platte z.B. Lesefehler etc. hat. Hat sie aber nicht.

Das Problem ist, dass - wie ein anderer User auch schon anmerkte - das Windows Power-Management aussteigt und zwar sofern die Platte an dem ASMedia-Controller hängt und nicht am Standard-Controller. Also hat entweder der Controller eine Macke oder der Treiber dafür.
PS: Im übrigen trat selbiger Fehler auch mit einer anderen Platte als der HD103SI auf. Ich wette, wenn ich stückweise nacheinander alle Platten an den ASMedia Controller anschließe, werden die stets dasselbe Problem aufzeigen, während diese am Chipset-Controller anstandslos vermuten.
 
dann schalte doch endlich das Energiesparen der Platten auf nie, damit geht es doch laut deinen Aussagen. Dann ist endlich Ruhe und dein System läuft.
 
Nun ja - ich gehe halt gerne den Sachen auf den Grund - insbesondere wenn hier auch ein Verweis auf den Treiber als Ursache gegeben wird. Auf Verdacht Sachen rauszuwerfen nur weil sie alt sind mag zwar das Symptom kurieren und eine schnelle Lösung sein - aber sicher kuriert sie nicht die Ursache.

Ich habe nun den im Tom's Hardware Forum besagten ASMedia-Treiber installiert (https://forums.tomshardware.com/threads/driver_power_state_failure-9f-bsod.3809299/) und seit dem keine BSOD-Screens mehr bekommen.

Sollte das auch in den nächsten Tagen so bleiben, war dies anscheinend die Ursache dafür gewesen. Anscheinend kommt dann der Windows-out-of-the-box Treiber offenbar nicht mit älteren Platten zurecht - wobei wir das mit neueren Platten ja auch noch nicht bewiesen haben... ASRock sollte dann darauf hinweisen und den Treiber in Ihr Chipset/Mainboard-Treiberpaket integrieren. Es kann auch sein dass viele Benutzer dies aber gar nicht bemerken, weil sie entweder SATA gar nicht mehr nutzen oder ihre SATA-Drives am X670E-Controller betreiben und nicht am ASMedia - wer nutzt denn schon mehr als 4 SATA Drives.
Ergänzung ()

IDontWantAName schrieb:
dann schalte doch endlich das Energiesparen der Platten auf nie, damit geht es doch laut deinen Aussagen. Dann ist endlich Ruhe und dein System läuft.
Siehe unten - anscheinend war es ein Treiberproblem mit den Standard-Windows-Treibern. Seitdem ich den ASMedia 106x Treiber installiert habe, läuft das System bis jetzt stabil. Ich denke wenn nächste Woche da nix mehr kommt, war es das dann wohl gewesen.
 
  • Gefällt mir
Reaktionen: Terrier
Update:
Nachdem ich die beschriebenen Änderung (Installation des ASMedia SATA 106x Drivers) vorgenommen habe, sind seit dem 23.6.2023 in der Tat keine weiteren Powerstate-BSODs mehr aufgetreten und das Problem ist durch die Installation des zugegebenermaßen recht alten Treibers behoben worden.
Mir ist komplett unverständlich das so etwas nicht früher bekannt wurde - m.E. sollte Microsoft ja die WHQL-Treiber mit in Windows integrieren.
Ich denke aber auch das das Ganze eventuell unter dem Radar fliegt da heutzutage Hard Drives nicht mehr in so großer Zahl eingesetzt werden, als dass bei 8 Ports eine ausgerechnet an den 4 ASMedia Ports welche betrieben werden - und an den anderen tritt der Fehler ja offenbar nicht auf.

Abschließend bleibt zu sagen
  • Der Austausch der SATA Kabel brachte nichts
  • Das Weglassen der "problematischen" HD103SI auch nichts, den der Fehler tritt auch mit anderen Platten
auf)
- Das Abschalten des Energiesparmodus der Platten "unterdrückt" den Fehler zwar, beseitigt aber nicht dessen
Ursache

Einzig die Installation des WHQL ASMedia 106x SATA Treibers, der noch aus Windows 10 stammt, scheint das Problem offenbar behoben zu haben.

Trotzdem nochmal vielen Dank Euch allen für die vielen Tips und Unterstützung.

Falls jemand diesen Thread liest und dasselbe Problem hat, verlinke ich nochmal zum Thread im englischsprachigen Tom's Hardware Forum.

https://forums.tomshardware.com/threads/driver_power_state_failure-9f-bsod.3809299/#post-23041040
 
  • Gefällt mir
Reaktionen: Teckler, whats4 und Terrier
Zurück
Oben