Windows Win11 - Blueschreen nach Modern Standby?

[ahoellrigl]

Mein Problem mit dem Modern Standby ist nicht ein leerer Akku (ich schalte meinen Rechner am Ende des Tages komplett aus), sondern teils erhebliche Probleme bis zum Absturz mit Bluescreen und Neustart dann, wenn das System zeitgesteuert in den Energiesparmodus geht.

Es handelt sich um ein P14s G1A mit einem Ryzen 7 PRO 4750U, den ich in einem Ultra-Dock 40AJ an einem Eizo FlexScan EV2495 betreibe. Das Problem ist nicht der Energiesparmodus an sich, sondern wohl nur das sukzessive "Einschlafen", wenn das System eine gewisse Zeitlang nicht benutzt wird. Wenn ich aktiv über das Ausschaltmenü oder mit

C:\Windows\System32\rundll32.exe powrprof.dll,SetSuspendState Sleep

(als Link auf dem Desktop eingerichtet) in den Energiesparzustand gehe, klappt das Aufwachen. Wenn der PC sich hingegen selber in den Energiesparmodus versetzt, muss ich oft tricksen und z.B. den Netzstrom kurz abschalten, damit das System aus PC, Dock und Monitor wieder aufwacht. Oder es kommt dabei zu besagten Abstürzen, wobei der Bluescreen dann so schnell verschwindet, dass nicht erkennbar ist, welcher Fehler ihn verursacht. Weil ich das P14s im Dock ja mit geschlossenem Deckel betreibe und den Bluescreen nur sehe, wenn ich den bei den Aufweckversuchen mal öffne. In der Ereignisanzeige habe ich auch noch keinen Hinweis auf eine Fehlerquelle gesehen, sondern immer nur Einträge, dass der PC unerwartet neu gestartet wurde.

Es geht mir hier aktuell nicht um eine detaillierte Fehlersuche. Meine Hypothese ist, dass die Probleme vom Modern Standby verursacht werden. Das würde ich also gerne deaktivieren, dabei aber die Option des "klassischen" Standby (SetSuspendState Sleep, siehe oben) behalten wollen. Ist das möglich?

 

[Mornsgrans]

Ich würde erst einmal anders ansetzen:
- Test ohne Dock
- BIOS/UEFI auf Updates prüfen
- Ereignisanzeige auf Fehlermeldungen zum Zeitpunkt des Standby-Versuchs überprüfen

 

[think_pad]

Wenn ich aktiv über das Ausschaltmenü oder mit
C:\Windows\System32\rundll32.exe powrprof.dll,SetSuspendState Sleep
als Link auf dem Desktop eingerichtet) in den Energiesparzustand gehe, klappt das Aufwachen.

Das ist aber nicht der Energiesparmodus, sondern der per Befehl erzwungene Ruhezustand, bei dem der Inhalt des RAM komplett auf die hyberfile.sys geschrieben wird und dann der Rechner komplett ausgeschaltet.

Beim Energiesparen gibt es entweder den S0- oder S3-Zustand des Gerätes, damit steht und fällt jegliche Energiesparstrategie. (In einigen Geräten kann man im BIOS zwischen WINDOWS und LINUX umschalten, das entspricht dann S0 oder S3. Hat man den Umschalter nicht, muss man nehmen, was der Befehl anzeigt.)

Man kann es mit dem Befehl

C:\Windows\System32\cmd.exe /k powercfg /a

ermitteln und dann hier posten.

Hat man ein S0-Gerät, kann den oben verlinkten Befehl nutzen, um im ausbalancierten Modus und im Batteriebetrieb die Netzverbindungen zu kappen, die das Gerät im Energiesparmodus wieder einschalten.

 

[ahoellrigl]

Ich würde erst einmal anders ansetzen:
- Test ohne Dock

Ist geplant - allerdings würde es mir nicht viel helfen, wenn es am Dock läge. Ich brauche halt die Konfiguration u.a. mit zwei Monitoren, die ich über das Dock realisiere.

- BIOS/UEFI auf Updates prüfen

Ist auf dem aktuellen Stand, Version 1.51, am 24.03. über Vantage aufgespielt.

- Ereignisanzeige auf Fehlermeldungen zum Zeitpunkt des Standby-Versuchs überprüfen

Man bekommt ja normalerweise nicht genau mit, wenn man z.B. eine Arbeitspause macht, wann genau der Rechner in den Schlafzustand wechselt. Ich habe mal die gesamte Liste auf "Fehler" und "Kritisch" gefiltert und bin sie dann auf "verdächtige" Abfolgen durchgegangen. Gefunden habe ich da z.B. so was.

Spoiler: Microsoft-Windows-NDIS

Protokollname: System
Quelle: Microsoft-Windows-NDIS
Datum: 02.05.2025 09:43:12
Ereignis-ID: 10317
Aufgabenkategorie: PnP
Ebene: Fehler
Schlüsselwörter: (16384),(16),(4),(2)
Benutzer: Nicht zutreffend
Computer: P14sG1A-Andreas
Beschreibung:
Für den Miniport "Microsoft Wi-Fi Direct Virtual Adapter #4, {a211134a-e03a-41ee-92f3-3b9d1436fafa}" ist das Ereignis "Fatal error: The miniport has failed a power transition to operational power" aufgetreten.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-NDIS" Guid="{cdead503-17f5-4a3e-b7ae-df8cc2902eb9}" />
<EventID>10317</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>2</Task>
<Opcode>0</Opcode>
<Keywords>0x2000000000004016</Keywords>
<TimeCreated SystemTime="2025-05-02T07:43:12.2832199Z" />
<EventRecordID>134014</EventRecordID>
<Correlation ActivityID="{a211134a-e03a-41ee-92f3-3b9d1436fafa}" />
<Execution ProcessID="4" ThreadID="11396" />
<Channel>System</Channel>
<Computer>P14sG1A-Andreas</Computer>
<Security />
</System>
<EventData>
<Data Name="IfGuid">{a211134a-e03a-41ee-92f3-3b9d1436fafa}</Data>
<Data Name="IfIndex">16</Data>
<Data Name="IfLuid">19985273169379328</Data>
<Data Name="AdapterName">Microsoft Wi-Fi Direct Virtual Adapter #4</Data>
<Data Name="MiniportEventEnum">74</Data>
</EventData>
</Event>

Der Fehler tritt mehrfach auf. Allerdings sehe ich keinen zeitlichen Zusammenhang mit protokollierten Abstürzen.

Hingegen hier eine Sequenz, wo dann auch ein Absturz protokolliert wird.

Spoiler: Microsoft-Windows-DistributedCOM

Protokollname: System
Quelle: Microsoft-Windows-DistributedCOM
Datum: 03.05.2025 01:22:09
Ereignis-ID: 10010
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: SYSTEM
Computer: P14sG1A-Andreas
Beschreibung:
Der Server "{995C996E-D918-4A8C-A302-45719A6F4EA7}" konnte innerhalb des angegebenen Zeitabschnitts mit DCOM nicht registriert werden.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-DistributedCOM" Guid="{1B562E86-B7AA-4131-BADC-B6F3A001407E}" EventSourceName="DCOM" />
<EventID Qualifiers="0">10010</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8080000000000000</Keywords>
<TimeCreated SystemTime="2025-05-02T23:22:09.0107108Z" />
<EventRecordID>134295</EventRecordID>
<Correlation ActivityID="{db227b92-bba9-000c-a07e-22dba9bbdb01}" />
<Execution ProcessID="1832" ThreadID="19836" />
<Channel>System</Channel>
<Computer>P14sG1A-Andreas</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="param1">{995C996E-D918-4A8C-A302-45719A6F4EA7}</Data>
</EventData>
</Event>

Direkt danach wurden noch drei analoge Fehler für die Server "{AB93B6F1-BE76-4185-A488-A9001B105B94}" um 01:25:02 Uhr, "{AB93B6F1-BE76-4185-A488-A9001B105B94}" und "{995C996E-D918-4A8C-A302-45719A6F4EA7}" um 01:28:10 Uhr gemeldet. Und danach eben:

Spoiler: EventLog

Protokollname: System
Quelle: EventLog
Datum: 03.05.2025 01:32:23
Ereignis-ID: 6008
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: P14sG1A-Andreas
Beschreibung:
Das System wurde zuvor am ‎03.‎05.‎2025 um 01:13:51 unerwartet heruntergefahren.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="EventLog" />
<EventID Qualifiers="32768">6008</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2025-05-02T23:32:23.6490555Z" />
<EventRecordID>134330</EventRecordID>
<Correlation />
<Execution ProcessID="3888" ThreadID="3976" />
<Channel>System</Channel>
<Computer>P14sG1A-Andreas</Computer>
<Security />
</System>
<EventData>
<Data>01:13:51</Data>
<Data>‎03.‎05.‎2025</Data>
<Data>
</Data>
<Data>
</Data>
<Data>6018</Data>
<Data>
</Data>
<Data>
</Data>
<Binary>E90705000600030001000D0033002802E90705000500020017000D0033002802DC0500003C00000001000000DC050000010000001E0000000000000000000000</Binary>
</EventData>
</Event>

Spoiler: volmgr

Protokollname: System
Quelle: volmgr
Datum: 03.05.2025 01:32:08
Ereignis-ID: 162
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:Klassisch
Benutzer: Nicht zutreffend
Computer: P14sG1A-Andreas
Beschreibung:
Generierung der Dumpdatei erfolgreich.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="volmgr" />
<EventID Qualifiers="4">162</EventID>
<Version>0</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2025-05-02T23:32:08.2144432Z" />
<EventRecordID>134338</EventRecordID>
<Correlation />
<Execution ProcessID="4" ThreadID="272" />
<Channel>System</Channel>
<Computer>P14sG1A-Andreas</Computer>
<Security />
</System>
<EventData>
<Data>\Device\HarddiskVolume3</Data>
<Binary>000000000100000000000000A2000400D90E00000000000000000000000000000000000000000000</Binary>
</EventData>
</Event>

Spoiler: Microsoft-Windows-Kernel-Power

Protokollname: System
Quelle: Microsoft-Windows-Kernel-Power
Datum: 03.05.2025 01:32:08
Ereignis-ID: 41
Aufgabenkategorie: (63)
Ebene: Kritisch
Schlüsselwörter: (70368744177664),(2)
Benutzer: SYSTEM
Computer: P14sG1A-Andreas
Beschreibung:
Das System wurde neu gestartet, ohne dass es zuvor ordnungsgemäß heruntergefahren wurde. Dieser Fehler kann auftreten, wenn das System nicht mehr reagiert hat oder abgestürzt ist oder die Stromzufuhr unerwartet unterbrochen wurde.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-Kernel-Power" Guid="{331c3b3a-2005-44c2-ac5e-77220c37d6b4}" />
<EventID>41</EventID>
<Version>10</Version>
<Level>1</Level>
<Task>63</Task>
<Opcode>0</Opcode>
<Keywords>0x8000400000000002</Keywords>
<TimeCreated SystemTime="2025-05-02T23:32:08.5912300Z" />
<EventRecordID>134343</EventRecordID>
<Correlation />
<Execution ProcessID="4" ThreadID="8" />
<Channel>System</Channel>
<Computer>P14sG1A-Andreas</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="BugcheckCode">268435582</Data>
<Data Name="BugcheckParameter1">0xffffffffc0000005</Data>
<Data Name="BugcheckParameter2">0xfffff80120e31fd5</Data>
<Data Name="BugcheckParameter3">0xffffae8511b72078</Data>
<Data Name="BugcheckParameter4">0xffffae8511b71860</Data>
<Data Name="SleepInProgress">0</Data>
<Data Name="PowerButtonTimestamp">0</Data>
<Data Name="BootAppStatus">0</Data>
<Data Name="Checkpoint">0</Data>
<Data Name="ConnectedStandbyInProgress">false</Data>
<Data Name="SystemSleepTransitionsToOn">0</Data>
<Data Name="CsEntryScenarioInstanceId">5</Data>
<Data Name="BugcheckInfoFromEFI">false</Data>
<Data Name="CheckpointStatus">0</Data>
<Data Name="CsEntryScenarioInstanceIdV2">5</Data>
<Data Name="LongPowerButtonPressDetected">false</Data>
<Data Name="LidReliability">false</Data>
<Data Name="InputSuppressionState">0</Data>
<Data Name="PowerButtonSuppressionState">0</Data>
<Data Name="LidState">1</Data>
<Data Name="WHEABootErrorCount">0</Data>
</EventData>
</Event>

Spoiler: Microsoft-Windows-WER-SystemErrorReporting

Protokollname: System
Quelle: Microsoft-Windows-WER-SystemErrorReporting
Datum: 03.05.2025 01:32:22
Ereignis-ID: 1001
Aufgabenkategorie:Keine
Ebene: Fehler
Schlüsselwörter:
Benutzer: SYSTEM
Computer: P14sG1A-Andreas
Beschreibung:
Der Computer wurde nach einem schwerwiegenden Fehler neu gestartet. Der Fehlercode war: 0x0000007e (0xffffffffc0000005, 0xfffff80120e31fd5, 0xffffae8511b72078, 0xffffae8511b71860). Ein volles Abbild wurde gespeichert in: C:\WINDOWS\Minidump\050325-18406-01.dmp. Berichts-ID: 4e4145b8-b022-470f-9c7b-a5ec3b0b4b48.
Ereignis-XML:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Microsoft-Windows-WER-SystemErrorReporting" Guid="{abce23e7-de45-4366-8631-84fa6c525952}" />
<EventID>1001</EventID>
<Version>1</Version>
<Level>2</Level>
<Task>0</Task>
<Opcode>0</Opcode>
<Keywords>0x8000000000000000</Keywords>
<TimeCreated SystemTime="2025-05-02T23:32:22.3405595Z" />
<EventRecordID>134392</EventRecordID>
<Correlation />
<Execution ProcessID="1516" ThreadID="1520" />
<Channel>System</Channel>
<Computer>P14sG1A-Andreas</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data Name="param1">0x0000007e (0xffffffffc0000005, 0xfffff80120e31fd5, 0xffffae8511b72078, 0xffffae8511b71860)</Data>
<Data Name="param2">C:\WINDOWS\Minidump\050325-18406-01.dmp</Data>
<Data Name="param3">4e4145b8-b022-470f-9c7b-a5ec3b0b4b48</Data>
</EventData>
</Event>

So richtig viel kann ich leider mit den Meldungen nicht anfangen. Tipps sind also willkommen.

 

[Mornsgrans]

Ist auf dem aktuellen Stand, Version 1.51, am 24.03. über Vantage aufgespielt.

Die Version wurde am 31.03. durch die gleiche Version ersetzt.


Ob der Dump etwas verwertbares auswirft, wäre zu überprüfen. Da wäre ich aber nicht der richtige Ansprechpartner - das fängt schon bei der Auswahl des Dump-Viewers an.


Zum Spoiler "NDIS":

English Community-Lenovo Community

Ich empfehle, erst einmal im Windows Befehlsfenster ("Als Administrator ausführen...") die Befehle
chkdsk /r /f C:
zur Behebung möglicher Dateisystem-Inkonsistenzen und nach Neustart
sfc /scannow
zur Behebung von Systemdateifehlern auszuführen.

Edit:
Abgekoppelt von https://thinkpad-forum.de/threads/win11-modern-standby-deaktivieren-aber-wie.243573/

 

[ahoellrigl]

Das ist aber nicht der Energiesparmodus, sondern der per Befehl erzwungene Ruhezustand, bei dem der Inhalt des RAM komplett auf die hyberfile.sys geschrieben wird und dann der Rechner komplett ausgeschaltet.

Beim Energiesparen gibt es entweder den S0- oder S3-Zustand des Gerätes, damit steht und fällt jegliche Energiesparstrategie. (In einigen Geräten kann man im BIOS zwischen WINDOWS und LINUX umschalten, das entspricht dann S0 oder S3. Hat man den Umschalter nicht, muss man nehmen, was der Befehl anzeigt.)

Man kann es mit dem Befehl

C:\Windows\System32\cmd.exe /k powercfg /a

ermitteln und dann hier posten.

powercfg /a meldet mir Folgendes.

Die folgenden Standbymodusfunktionen sind auf diesem System verfügbar:
Standby (S0 Niedriger Energiestand – Leerlauf) Netzwerk verbunden
Ruhezustand

Die folgenden Standbymodusfunktionen sind auf diesem System nicht verfügbar:
Standby (S1)
Die Systemfirmware unterstützt diesen Standbystatus nicht.
Dieser Standbystatus ist deaktiviert, wenn der energiesparende S0-Leerlauf unterstützt wird.

Standby (S2)
Die Systemfirmware unterstützt diesen Standbystatus nicht.
Dieser Standbystatus ist deaktiviert, wenn der energiesparende S0-Leerlauf unterstützt wird.

Standby (S3)
Die Systemfirmware unterstützt diesen Standbystatus nicht.
Dieser Standbystatus ist deaktiviert, wenn der energiesparende S0-Leerlauf unterstützt wird.

Hybrider Standbymodus
Standby (S3) ist nicht verfügbar.
Dieser Standbyzustand wird von Hypervisor nicht unterstützt.

Schnellstart
Diese Aktion ist in der aktuellen Systemrichtlinie deaktiviert.

Ich hatte vergessen zu erwähnen, dass ich den Windows-Schnellstart bereits in der klassischen Systemsteuerung deaktiviert habe. In den Netzschalter-, Energiespartasten- und Zuklappeinstellungen steht alles auf "Energie sparen", außer Zuklappen im Netzbetrieb, das ist auf "Nichts unternehmen" eingestellt.

Hat man ein S0-Gerät, kann den oben verlinkten Befehl nutzen, um im ausbalancierten Modus und im Batteriebetrieb die Netzverbindungen zu kappen, die das Gerät im Energiesparmodus wieder einschalten.

Wie gesagt, mein Problem ist nicht, dass das Gerät Strom zieht, wo es nicht soll oder sich unngewollt wieder einschaltet. Sondern eher im Gegenteil, dass das Aufwachen nach dem zeitgesteuerten Einschlafen nicht vernünftig funktioniert.

 

[think_pad]

Wie gesagt, mein Problem ist nicht, dass das Gerät Strom zieht, wo es nicht soll oder sich ungewollt wieder einschaltet. Sondern eher im Gegenteil, dass das Aufwachen nach dem zeitgesteuerten Einschlafen nicht vernünftig funktioniert.

Das kann alles Mögliche sein:

• rein theoretisch dürfte das Gerät gar nicht "einschlafen"
• AMD-Geräte hatten schon immer Schwierigkeiten mit S0
• falscher Powermanager
• angeschlossene Geräte, die in den Sleepmodus geschickt werden und dann nicht wieder aufwachen

 

[Mornsgrans]

angeschlossene Geräte, die in den Sleepmodus geschickt werden und dann nicht wieder aufwachen

Darauf deutet zumindest der NDIS-Fehler hin. Genaueres könnte der Minidump ergeben.

 

[ahoellrigl]

So, ein kleines Update. Bei chkdsk /r /f C: und sfc /scannow wurden keine Fehler gefunden.

Ich habe dann das P14s probehalber mal per USB-C-Kabel direkt an den Eizo-Monitor angeschlossen (der funktioniert als Dock mit KVM-Switch, normalerweise hänge ich da mein dienstliches ThinkPad dran). Und da ist das Problem mit dem Hängenbleiben im Ruhezustand bzw. Absturz beim Aufweckversuch jetzt bei drei Versuchen hintereinander mit unterschiedlich langen Wartezeiten nach dem Beginn des Schlafmodus nicht aufgetreten. Ich konnte das ThinkPad jeweils ohne Verzögerung durch einen Tastendruck auf der am Monitor hängenden externen Tastatur (Logitech MX Keys) wieder aufwecken.

Sollte sich das bei weiteren Versuchen bestätigen, wäre das ein Indiz dafür, dass die Probleme ihren Ursprung im UltraDock 40AJ haben. Oder im Zusammenspiel des Docks mit dem AMD-ThinkPad und dem Eizo-Monitor.

Ich schaue mir das jetzt weiter an. Werde auch mal versuchen, wie sich ein Intel-ThinkPad in Bezug auf den Schlafmodus am 40AJ-Dock verhält.

Die Sache mit dem NDIS-Fehler lasse ich zunächst einmal außen vor. Ich beobachte im Betrieb keine WiFi-Probleme, und einen direkten zeitlichen Zusammenhang mit dem Schlafmodus und den Abstürzen bei Aufweckversuchen scheint es nicht zu geben.

 

[HolyBimBam]

Probleme ihren Ursprung im UltraDock 40AJ haben. Oder im Zusammenspiel des Docks mit dem AMD-ThinkPad und dem Eizo-Monitor.

Dock-Firmware aktualisiert ?

ThinkPad Basic Docking Station (40AG), Pro Docking Station (40AH), Ultra Docking Station (40AJ) Station Firmware Utility - Lenovo Support DE

pcsupport.lenovo.com

 

[ahoellrigl]

Dock-Firmware aktualisiert ?

Bin mir ziemlich sicher, ja. Die letzte Version stammt ja von 2022, bevor ich das ganze jetzige Equipment hatte. Und üblicherweise aktualisiere ich so etwas direkt, wenn ich ein Gerät in die Finger kriege. Außerdem nutze ich Vantage und ich meine, da würde es auch angeboten, wenn ein Dock erkannt wird.

Kennt jemand einen einfachen Weg, den Versionsstand der Firmware eines 40AJ-Docks auszulesen?

 

[HolyBimBam]

Kennt jemand einen einfachen Weg, den Versionsstand der Firmware eines 40AJ-Docks auszulesen?

Siehe readme zum oben verlinkten Firmware-Update:

-- Command for Silent deployment in other environment:
           1>. Extract the file to a local directory with command:
               n20pf*.exe /VERYSILENT /EXTRACT="YES" /DIR="c:\cs18-dock"
           2>. Enter the directory: cd c:\cs18-dock
[...]
           4>. Check version
               command: cs18_cmd.exe /v 
               Return code:
                      0: Checking version successfully, firmware update is not needed (dock’s firmware is equal to or newer than package’s).
                      1: Checking version successfully, firmware update is needed (dock’s firmware is older than package’s).
                     -1: Checking version failed due to dock not found or other unknown reason.
                    -10: Checking version failed due to failure on Audio chip.
                    -20: Checking version failed due to failure on USB Hub chip.
                    -30: Checking version failed due to failure on DP chip.
                    -40: Checking version failed due to failure on PD chip.

 

[ahoellrigl]

Danke. Ich hatte das Readme zwar eben auch überflogen, aber irgendwie war mir das durchgerutscht. Wird wohl langsam Zeit für eine Mittagspause... Ich schaue mir das an, wenn ich nach der Arbeit wieder zu Hause bin.

Beitrag automatisch zusammengeführt: 6 Mai 2025

Tja... Das Firmware-Update hatte ich wohl beim Vorgänger des aktuellen Docks gemacht. Das letztes Jahr im Juli mit einem Defekt ausgefallen war. Beim Nachfolger anscheinend nicht. Habe ich jetzt nachgeholt. Und beobachte weiter.

 

[der_ingo]

Falls es weiter auftaucht, kann wirklich nur der Crashdump eventuell mehr aussagen. In dem Fall stell den doch bitte mal online.

 

[ahoellrigl]

Ich beobachte noch. Aktuell sieht es nach dem Firmware-Update beim Dock (und ich war mir eigentlich sooo sicher gewesen, dass ich das schon gemacht hätte... tja...) ganz gut aus - bislang keine Probleme beim Aufwecken des Rechners nach unterschiedlich langen Wartezeiten und auch keine Abstürze. Mal sehen, ob das so bleibt.