P15* P15v Gen3 AMD - Absturz im Standby/Hibernate immer Montags früh

[bemymonkey]

Morgen zusammen!

Pünktlich zum Feiertag nach Halloween etwas Skurriles: Mein P15vG3 stürzt immer zuverlässig Montags ab. Ich steige um 08:15 in den Zug Richtung Büro, klappe das Teil auf und es bootet komplett durch bis zu einer frischen Session - egal ob das Gerät zuvor im Hibernate oder im Standby war.

Anfangs hatte ich das auf meine Debian Sid Installation geschoben, allerdings habe ich vor einem Monat oder zwei auf die Maschine ein Win10Pro Clean Install drauf gebügelt (Nur Windows Updates + Commercial Vantage). Das Verhalten tritt weiterhin zuverlässig auf - jeden Montag gegen 8:00. Teilweise habe ich mit dem Gerät um 7:00 zuhause noch normal gearbeitet - zusammen geklappt (=> Standby), im Zug wieder aufgeklappt und die Session ist weg.

Der Event Viewer zeigt dann immer einfach den üblichen Kernel-Power Fehler mit Event-ID 41.



Logs vom Debian System habe ich keine mehr, da ich dachte das Problem würde mit dem Wechsel zurück auf Windows verschwinden. Aus dem Event Viewer kann ich natürlich noch beliebige Einträge raus holen falls interessant.

Das Einzige was mir als mögliche Ursache einfällt ist ein (weiterer) merkwürdiger Bug im UEFI/EC. Lenovo hat sich bei der AMD Version des P15vG3 was das angeht ohnehin nicht mit Ruhm bekleckert (es gab von Anfang an viele Probleme mit Standby/Hibernate und vor Allem das wieder Aufwachen aus dem Hibernate). Alle Dinge wie RTC Wake-Timer im UEFI sind natürlich aus. Ich bin vor ein paar Tagen nochmal durchgestiefelt und habe auch alles was ich nicht zwingend brauche abgeschaltet - hat bisher nicht geholfen.

Das Gerät ist bis auf eine ersetzte Tastatur (DE auf US) 100% original. Ich dachte schon vielleicht hat die neue Tastatur eine Macke, aber dann wundert mich die zeitliche Komponente an dem Phänomen.

Hat jemand schon mal solches Verhalten gesehen oder vielleicht eine Idee, woran das liegen kann?

 

[cuco]

Gab's nicht mal so einen kuriosen Bug im Linux Druckerdienst, so dass man zu bestimmten Zeiten bzw. an bestimmten Tagen immer nicht mehr drucken konnte? Oder nur noch schwarz weiß aber nicht mehr in Farbe? Finde leider gerade keine Quelle mehr, aber das hier erinnert mich daran

Tut mir leid für Offtopic, aber ich habe gerade den Bug wiedergefunden, wo ein Drucker Dienstags nicht aus OpenOffice unter Linux druckt: https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/255161/comments/28 An anderen Tagen oder mit anderen Tools dagegen geht es.
Im Endeffekt lag es hier dran: https://bugs.launchpad.net/ubuntu/+source/file/+bug/248619
Aber das nochmal zum Thema kuriose Bugs. Bis man darauf kommt, dass er nur Dienstags nicht druckt und nur aus OpenOffice nicht mag...

 

[bemymonkey]

Moin zusammen, gibt neue Infos:

Gerade eben Rechner aufgeklappt und er ist mal wieder zu einer frischen Session durchgebootet. Interessant dabei:

1. haben wir Freitag
2. bin ich daheim
3. gibt es dieses Mal eine "Bugcheck" Meldung im Event Viewer (die gab's sonst nie)

The computer has rebooted from a bugcheck. The bugcheck was: 0x0000009f (0x0000000000000003, 0xffffe508157abc40, 0xfffffc09468ef810, 0xffffe5080fb11010). A dump was saved in: C:\Windows\MEMORY.DMP. Report Id: 8176d657-7b6d-4f49-9879-fed5e96256f5.

Dazu gibt es noch eine Fehlermeldung Event 16 Kernel-Boot:


Ich werde mich mal auf die Suche nach Analyse-Tools für den Memory-Dump machen. Googlen der einzelnen Bugcheck-Codes (sollen das tatsächlich Fehlercodes sein oder eher Speicheradressen o.Ä.?) gibt keinerlei sinnvolle Ergebnisse, größere Teile der Meldung führen halt zu irgendwelchen allgemeinen BSOD Support-Anfragen ohne viel Symptom-Details.

Der Versuch, WinDbg zum Analysieren des Memory Dump von einem offiziellen Microsoft-Link aus zu installieren endet erst mal auch in einer Fehlermeldung... das liegt aber immerhin jetzt an Windows und nicht an EC/UEFI/Plattform:


Googlen der Event 16 Fehlermeldung gibt die üblichen Hotline-Ergebnisse - Treiber updaten usw.

Ereignis-ID 41 Das System wurde neu gestartet, ohne zuerst sauber herunterzufahren. - Windows Client

Beschreibt die Umstände, die dazu führen, dass ein Computer Ereignis-ID 41 generiert, und enthält Anleitungen zur Problembehandlung.

learn.microsoft.com

Darauf hatte ich leider vergessen zu antworten. Ausschnitt aus dem Link:

Dieser Schlüssel kann bei der Behandlung von Startproblemen hilfreich sein, um zu ermitteln, ob das System falsch ausgeschaltet wurde.


Sie können auch alle Werte (z. B. DirtyShutdown, LastAliveStamp, TimeStampInterval) im folgenden Registrierungsschlüssel löschen: Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Reliability. Dadurch kann verhindert werden, dass die Ereignisnachverfolgung zum Herunterfahren nach einem unerwarteten Herunterfahren angezeigt wird.

Löschen des Registry-Schlüssels bewirkt also nur, dass der Event Viewer die Fehlermeldung nicht mehr anzeigt weil die entsprechenden Diagnosedaten fehlen... was soll das denn bringen?




Sollte die Analyse des Memory-Dumps nicht fruchten werde ich das Thema begraben und damit leben, dass der Rechner macht was er will... danach gibt es nur noch Mainstream-Modelle (X13, T14) mit Intel-Alles ohne dGPU, so wie im Privatleben.

Meine Vermutung ist weiterhin, dass die Kernursache der verlorenen Session in Lenovos/AMDs EC und UEFI FW für diese Ryzen Plattform liegt, da die Symptome OS-unabhängig auftreten und teilweise (weniger als 100% stabile Win10Pro Werksinstallation, Probleme beim Resume von Standby und Hibernate) auch bereits zuvor beim T14G3 AMD auftraten. Die zeitliche Komponente bleibt ein Mysterium, ist aber durch den heutigen Fehler widerlegt und vermutlich durch Nutzerverhalten zu erklären.

Ich danke Euch erst mal allen für die Teilnahme und Hilfestellung