Absturz Energiesparmodus Windows 10

[MilesEdgeworth]

Seit einiger Zeit kommt es auf meinem System des Öfteren dazu, dass es sich beim Aktivieren des Energiesparmodus (Suspend to RAM) aufhängt. In diesem Zustand funktioniert nicht einmal mehr die Reset Taste, das Gedrückt-Halten der Power-Taste ist der einzige Ausweg. Die Windows-Ereignisanzeige liefert leider keinerlei hilfreiche Information (wer hätte das gedacht ).

Hat denn jemand ähnliches beobachtet? Würde mich über Anregungen und Vorschläge jeglicher Art freuen!


Was mir aufgefallen ist:
Die verbauten Festplatten fahren sich üblicherweise während der Systemnutzung nach einiger Zeit herunter, da ich nur selten auf diese zugreife. Funktioniert der Übergang in den Energiesparmodus ordnungsgemäß werden die Platten vor der Systemdeaktivierung wieder kurz hochgefahren. Das passiert jedoch nicht, wenn der Rechner sich aufhängt. Jedoch habe ich zu keinem Zeitpunkt an irgendwelchen SATA- oder Festplatten-Treibern herumgespielt.

Zu meinem System:

Intel Core i7 6700K
Gigabyte Z170XUD5 TH
4x8GB HyperX FURY DDR4-2666 DIMM CL15
Seasonic X-460 Fanless Platinum

Samsung SSD SM951-NVMe 256GB
Western Digital WD Green 2TB
Western Digital WD Red 2TB
Samsung SSD 840 Pro 128GB
Samsung SSD 840 Evo 120GB

 

[NatokWa]

Wleche Art des Energiespar-Moduses nutzt du überhaupt ? Suspend to RAM , oder RAM-Image-to-HDD ? Da sich das Prinziep gewaltig unterscheidet ist es wichtig zu wissen welchen Mode du nutzt um evtl die Fehler die auftretten leichter finden zu können .

 

[MilesEdgeworth]

Suspend to RAM wird verwendet, ich ergänze den Startpost noch entsprechend!

 

[NatokWa]

Ok . Jetzt ist der nächste Schritt zu prüfen ob das Speicherabbild in den Absturzfällen auch GESCHRIEBEN wird , oder obs schon vorher aussteigt . Das kannst du natürlich nur herrausfinden indem du die eigenschaften der Abbilddatei prüfst nachdem der Rechner neu gestartet hat ODER startet der Rechner mit dem Abblid nach dem Absturz "normal"(Alla wacht auf) ? Dazu hast du nämisch leider keine Angabe gemacht ob der "normal" startet oder wie ein "Aufwachen" .
Der Teufel liegt leider oft im kleinsten Detail . Je genauer wir wissen WANN genau der absturz statfindet , desto eher ist was über die möglichen Gründe auf zu spüren .

ALlerdings kannst du mal testen ob der ABsturz ohne die HDD's angeschloßen zu haben auch stattfindet . Ich hatte selbst bis vor kurzem ne WD-Green und die hat diverse Probs wie verzögerter Sys-Start etc. verursacht . KANN natürlich an meiner Platte gelegen haben , aber auszuschließen ist NICHTS (derzeit) .

 

[MilesEdgeworth]

Zurzeit liegt mir leider kein Speicherabbild im Minidump Verzeichnis vor, das ich auslesen lassen könnte. Nach dem Absturz startet das System ganz normal (kaltstart). Die Ereignisanzeige liefert, dass das System nicht ordnungsgemäß heruntergefahren wurde, weitere Auffälligkeiten gibt es aber keine!
Die Festplatten habe ich zwar schon länger verbaut (die neuste Komponente ist tatsächlich die Samsung NVMe SSD), aber ich werde bei Gelegenheit mal die Platten abtrennen.

Danke schon einmal!

 

[NatokWa]

Das Speicherabbild fürs Suspend-to-RAM wird NICHT im Minidump-Ordner abgelegt , sondern als versteckte Datei unter C:\ . Der MInidump Ordner ist schließlich "nur" ein Ordner für Fehlerberichte etc. .
Außerdem kann man das Suspend-File auch net "auslesen" , schließlich isset kein Bericht sondern der tatsächliche Inhalt vom RAM zum zeitpunkt des Go-to-Suspend Befehls .

Habe diese Funktion unter Win10 selbst noch net genutzt , aber ältere Win-Versionen hatten die angewohnheit diese datei NIE zu löschen , sondern nur zu ersetzen , einfach damit der Platz den das Teil braucht auch wirklich verfügbar ist (in größe des verbauten RAM's) was natürlich heist das du dafür 32GB versenkst . Hast du jetzt KEINE versteckte Speicherabbild-Datei auf deinem System + keine 32GB auf deiner C Platte frei KANN das der Grund sein , muss aber net . Win ist teils leider Strunzdoof und stürzt lieber ab als einem zu sagen : Da stimmt wat net , dat geht net .

Oh man ... ne jetzt lösch ich net .... ich DEPP ....Suspend to RAM ...... ich frag noch und schreibe alles was für Suspend to HDD gilt ..... nenn mich dumm ........ UFF !!! Suspend to RAM hat natürlich KEINE Abbilddatei auf der Platte ........ MAN !!

Ok nochmnal von vorne .....

Es KÖNNTE dein Netzteil sein . Ich errinere mich daran das es probleme gab das einige Netzteile die niedrigen Stöme die für Suspend-to-RAM nötig sind , nicht stabil liefern können . schließlich wird da ja nur noch der RAM und einige kleinere Schaltkreise mit Strom versorgt . Deswegen ziehen die meisten (welche unbedingt Suspend nutzen wollen) Suspend-to-HDD vor . Es können aber auch andere Teile in deinem Sys instabil sein , evtl ist sogar der MOdus nicht richtig im Bios eingerichtet bzw du hast nicht das aktuellste Bios und Win spricht es falsch an .... wie aktuel IST dein Bios ? Sind sämtliche Power-States im Bios aktiviert ?

 

[MilesEdgeworth]

Oh man ... ne jetzt lösch ich net .... ich DEPP ....Suspend to RAM ...... ich frag noch und schreibe alles was für Suspend to HDD gilt ..... nenn mich dumm ........ UFF !!! Suspend to RAM hat natürlich KEINE Abbilddatei auf der Platte ........ MAN !!

Ok nochmnal von vorne .....

Es KÖNNTE dein Netzteil sein . Ich errinere mich daran das es probleme gab das einige Netzteile die niedrigen Stöme die für Suspend-to-RAM nötig sind , nicht stabil liefern können . schließlich wird da ja nur noch der RAM und einige kleinere Schaltkreise mit Strom versorgt . Deswegen ziehen die meisten (welche unbedingt Suspend nutzen wollen) Suspend-to-HDD vor . Es können aber auch andere Teile in deinem Sys instabil sein , evtl ist sogar der MOdus nicht richtig im Bios eingerichtet bzw du hast nicht das aktuellste Bios und Win spricht es falsch an .... wie aktuel IST dein Bios ? Sind sämtliche Power-States im Bios aktiviert ?

Kein Thema, das passiert uns doch allen mal!

Von Suspend to Disk bin ich kein großer Fan, schließlich ist es maximal marginal schneller als ein vollständiges Hochfahren des Systems.

Das Netzteil ist eigentlich erst eineinhalb oder zwei Jahre alt, habe es nicht allzulange vor dem Skylake Umstieg gekauft. Auch auf die Powerstate Zertifizierung habe ich damals in Anbetracht eines möglichen Umstiegs bereits geachtet.
Wenn der Crash auftritt läuft das System noch mehr oder weniger weiter (es scheint, als wären alle Komponenten mit Strom versorgt, zumindest die Grafikausgabe ist jedoch deaktiviert), es wirkt eher, als würde eine Komponente nicht richtig deaktiviert werden.
Das Netzteil wird auch nicht "heruntergefahren", wenn man das so nennen möchte, das übliche "Klacken" tritt nämlich nicht auf. Da ich kein alternatives Netzteil parat habe, würde ich also erstmal an anderer Stelle weitersuchen.

Das BIOS ist nicht in der aktuellsten Fassung installiert, es wurde vor kurzem ein Update zur Unterstützung der Kabylake CPUs veröffentlicht. Die Updates verlaufen bei mir jedoch nicht gerade reibungslos, weshalb ich sie gerne vermeide(*). Jedoch ist das aktuelle BIOS schon deutlich länger installiert als die Probleme auftreten. Powerstates jeglicher Art sind konfiguriert.
Das System lief übrigens zwischen Januar (Systemaufbau) und Juli oder August völlig absturzfrei (mit dem gleichen Netzteil und BIOS). Es passiert auch relativ selten - nervig ist es natürlich dann trotzdem.
Mitte Juni sind dann zwei weitere RAM Riegel und die NVMe SSD dazu gekommen (Neuinstallation inklusive). Das erste Mal ist das Problem aber wohl erst zwei Monate später aufgetreten, einen direkten Zusammenhang würde ich also nicht vermuten.
Am häufigsten ist es wohl zwischen Ende September und Ende Oktober gewesen (laut Ereignisanzeige). In der Zeit habe ich auch relativ viel mit MATLAB gearbeitet, wobei ich das Programm vor dem Energiesparmodus vorsichtshalber immer beende.

Das Ausschließen von Komponenten ist leider sehr mühsam, da die Abstürze nicht ohne Weiteres reproduzierbar sind. An die Festplatten werde ich mich aber bei Gelegenheit wagen.


(*) Nach dem Update gibt es zunächst immer Probleme mit irgendeiner ACPI Komponente (mehr konnte ich leider nicht rausfinden). Dabei läuft dann ein CPU Kern konstant auf Volllast - ungeachtet des Betriebssystems. Bei Gigabyte konnte man das Problem auch nicht reproduzieren. Nur ein CMOS Reset verschafft dann Abhilfe - nicht schlimm, aber doch lästig.

 

[NatokWa]

Ok , das Problem mit der ACPI-Komponente ist schon mal ein Anhaltspunkt , schließlich kümmert sich das ACPI System um die Powerstates + Suspend Funktionen .

So sieht es jetzt für mich eher danach aus als währe das Board selbst das Problem . Fehlfunktionen am Board selbst habe ich bisher immer recht gut mit Progis wie Sissoftware Sandra u.ä. gefunden . Wenn das feststellt das was net stimmt zeigt es einem gleich an WO und was man machen kann bzw. obs reparabel ist .
BTW : Wenn die ereignissanzeige DOCH ergebnisse liefert : Welcher Fehlercode in welchem Programm/Prozess ?

 

[MilesEdgeworth]

Ich werde mal SiSoft Sandra bemühen. Die Ereignisanzeige sagt nur, dass das System unerwartet heruntergefahren wurde (ich muss ja schließlich die Powertaste gedrückt halten). Mehr Information habe ich leider nicht..

 

[NatokWa]

dann hofen wir mal das die gute Sandra was findet , evtl mal die einzelnen Komponenten (gerade RAM und CPU) Stresstesten ob es da auffälligkeiten gibt . Irgendwo muss der Hund ja begraben liegen .

 

[MilesEdgeworth]

Ich versuche gerade mit dem Tool etwas durchzusteigen, wirklich neue Informationen konnte ich noch nicht ziehen, werde mich aber noch einmal ausführlicher damit beschäftigen. Ehrlich gesagt halte ich aber ein Software-Problem fast für wahrscheinlicher als einen Hardware-Defekt.. Ich habe noch eine parallele Fedora Installation zur Verfügung, eventuell sollte ich dort mal oft in den Energiesparmodus und zurück wechseln. Bisher ist dort aber noch kein derartiges Problem aufgetreten.

Das ACPI Problem tritt ja nur vor einem CMOS Reset auf, daher würde ich davon ausgehen, dass einfach bei einem BIOS Update irgendwas durcheinander gebracht wird.

 

[MilesEdgeworth]

Heute habe ich den SiSoft Sandra BurnIn Test laufen lassen. Es sind jedoch keine Abstürze o.ä. aufgetreten, nach dem Abschluss ist das System ordnungsgemäß in den Energiesparmodus gewechselt.