Apps, die nach dem Fortsetzen aus dem Schlaf kaputtgehen — Energieereignisse und Geschäftsanwendungen, die das Fortsetzen überstehen

Sie schließen den Laptop, öffnen ihn am nächsten Morgen, und die Geschäftsanwendung ist voller Fehler. Eine Geräteüberwachungs-App verliert Daten nur nach der Mittagspause. Ein Hintergrundtool, das nach Excel exportiert, bleibt gelegentlich mit einem Verbindungsfehler stehen. Bei solchen Symptomen ist das Erste, das Sie verdächtigen sollten, das Verhalten über den Schlaf hinweg.

Manche herkömmlichen Geschäftsanwendungen wurden unter der Annahme geschrieben, dass „der PC anbleibt“. Nachdem Laptops in den Mittelpunkt der täglichen Arbeit gerückt sind, lässt sich eine Umgebung nicht mehr ignorieren, die nach wenigen Minuten Leerlauf schläft. Hinzu kommt: Maschinen mit Modern Standby schlafen nach einem anderen Mechanismus als dem herkömmlichen.

Dieser Artikel richtet sich an Entwickler, die Geschäftsanwendungen und Gerätesteuerungssoftware unter Windows bauen. Er ordnet anhand von Primärquellen die Benachrichtigungen, die das Betriebssystem liefert, was nach dem Fortsetzen kaputtgeht, wie Sie die Erholung entwerfen und wie Sie vor Ort untersuchen, in dieser Reihenfolge.

1. Zuerst das Fazit

Im Zentrum des Entwurfs steht nicht „vor dem Schlaf immer aufräumen“, sondern „sich nach dem Fortsetzen erholen können, egal wann die Maschine stoppt“. Drei Punkte sind festzuhalten.

• Die Vorabbenachrichtigung ist keine Garantie, dass Sie fertig werden. Schlaf lässt sich nicht ablehnen, und die Schonfrist von PBT_APMSUSPEND beträgt etwa 2 Sekunden. Bei einem Notfall-Suspend kommt die Benachrichtigung gar nicht. Auch unter Modern Standby dürfen Sie nicht annehmen, dass eine Desktop-App während des Schlafs weiterläuft.¹²³
• Entwerfen Sie unter der Annahme, dass Verbindungen, Handles und die Kontinuität der Zeit über das Fortsetzen hinweg nicht erhalten bleiben. Führen Sie nicht nur die Fortsetzungsbenachrichtigung, sondern auch Kommunikationsfehler in dieselbe Wiederverbindungsarbeit, und überdenken Sie auch Timer-Zeitpläne und Differenzen der verstrichenen Zeit.
• Schlafunterdrückung und die Vorbereitung auf das Fortsetzen sind getrennte Maßnahmen. Nutzen Sie SetThreadExecutionState oder eine Energieanforderung für die Arbeitsintervalle, die sie brauchen, und heben Sie sie danach immer auf. Eine ausdrückliche Schlafaktion des Benutzers lässt sich damit nicht verhindern, also ist sie kein Grund, die Erholungslogik wegzulassen.⁴⁵

Sie können auch bei dem Kapitel einsteigen, das zu Ihrem Ziel passt.

2. Was rund um den Schlaf passiert — Ablauf der Energieereignisse

Das Betriebssystem benachrichtigt Apps über Änderungen des Energiezustands durch die Nachricht WM_POWERBROADCAST.² Zuerst die drei Ereignisse, die rund um den Suspend-Übergang genutzt werden. Wie sich der energiesparende Leerlauf von Modern Standby davon unterscheidet, ergänzt Kapitel 3.

sequenceDiagram
    accTitle: Benachrichtigungsablauf für Schlaf und Fortsetzen
    accDescr: PBT_APMSUSPEND kommt kurz vor dem Schlaf mit etwa 2 Sekunden Schonfrist; beim Fortsetzen kommt PBT_APMRESUMEAUTOMATIC immer an, und PBT_APMRESUMESUSPEND folgt nur bei vom Benutzer ausgelöstem Fortsetzen
    participant OS as OS
    participant A as App
    OS->>A: PBT_APMSUSPEND (etwa 2 Sekunden Schonfrist)
    A->>A: Zustand speichern und Verbindungen schließen
    Note over OS: Schlaf (Code läuft nicht)
    OS->>A: PBT_APMRESUMEAUTOMATIC (kommt beim Fortsetzen an)
    A->>A: Wiederverbinden und Zustand wiederherstellen
    OS->>A: PBT_APMRESUMESUSPEND (nur benutzergesteuertes Fortsetzen)
    A->>A: Bildschirmaktualisierungen und andere benutzerseitige Arbeit

Abbildung 1: Die Benachrichtigungen sind nur „ein Wort kurz vorher und ein oder zwei Worte nach dem Fortsetzen“. Die Arbeit auf der Fortsetzungsseite treibt die Erholung.

Die Vorabbenachrichtigung vor dem Schlaf ist die Chance, „sich vorzubereiten, wenn es zeitlich reicht“

PBT_APMSUSPEND ist die Benachrichtigung unmittelbar vor dem Eintritt in den Schlaf. Sie erlaubt, Dateien zu schließen und den Zustand zu speichern, hat aber die folgenden zwei Einschränkungen.

Daher hält ein Entwurf nicht, der „nach Empfang dieser Benachrichtigung das Speichern immer zu Ende bringt“. Nutzen Sie die Vorabbenachrichtigung, um vorzubereiten, was noch rechtzeitig geht, und legen Sie die Substanz der Erholung auf die Fortsetzungsseite.

flowchart TB
    accTitle: Unterschied zwischen gewöhnlichem Schlaf und Notfall-Suspend
    accDescr: Gewöhnlicher Schlaf liefert kurz vorher PBT_APMSUSPEND mit etwa 2 Sekunden zur Vorbereitung, aber ein Notfall-Suspend durch kritischen Akku oder Ähnliches stoppt ohne Vorabbenachrichtigung, sodass ein Entwurf, der von der Vorabbenachrichtigung abhängt, nicht hält
    n2["Gewöhnlicher Schlaf"] --> pre["PBT_APMSUSPEND (etwa 2 Sekunden Schonfrist)"]
    pre --> s1["Vorbereiten, dann stoppen"]
    e2["Notfall-Suspend (Akku fast leer)"] --> s2["Stoppen ohne Vorabbenachrichtigung"]
    s2 -.-> l2["Ein Entwurf, der die Benachrichtigung voraussetzt, hält nicht"]

Abbildung 2: Ein Notfall-Suspend kommt ohne Vorwarnung. Vorbereitung ist also „ein Bonus, wenn sie rechtzeitig fertig wird“, und die Substanz liegt auf der Fortsetzungsseite.

Fortsetzungsbenachrichtigungen trennen mechanische Erholung und benutzerseitige Arbeit

Beim Fortsetzen aus dem Suspend kommt zuerst PBT_APMRESUMEAUTOMATIC an. Wenn die Maschine wegen der Ein-/Aus-Taste oder eines Tastendrucks fortgesetzt hat, oder wenn nach dem Fortsetzen Benutzerpräsenz erkannt wurde, folgt PBT_APMRESUMESUSPEND.⁶⁷

Dagegen kommt bei einem unbeaufsichtigten Fortsetzen, etwa einem Remote-Aufwachen über das Netz oder einem Fortsetzen zur Wartung, nur PBT_APMRESUMEAUTOMATIC an. Legen Sie notwendige Erholung wie das Neuaufbauen von Verbindungen auf Erstere und benutzerseitige Aktionen wie Bildschirmaktualisierungen oder eine erneute Anmeldeaufforderung auf Letztere.⁶

flowchart TB
    accTitle: Arbeit auf die zwei Fortsetzungsstufen aufteilen
    accDescr: Legen Sie mechanische Erholung wie Wiederverbinden auf PBT_APMRESUMEAUTOMATIC, das beim Fortsetzen ankommt; legen Sie benutzerseitige Arbeit wie Bildschirmaktualisierungen oder eine erneute Anmeldeaufforderung auf PBT_APMRESUMESUSPEND, das nur bei vom Benutzer ausgelöstem Fortsetzen ankommt
    ra["PBT_APMRESUMEAUTOMATIC (beim Fortsetzen)"] --> m["Mechanische Erholung"]
    rs["PBT_APMRESUMESUSPEND (benutzergesteuertes Fortsetzen)"] --> u["Benutzerseitige Arbeit"]
    m -.-> m1["Wiederverbinden und Handles neu öffnen"]
    u -.-> u1["Bildschirmaktualisierungen und erneute Anmeldeaufforderung"]

Abbildung 3: Die Letztere kommt bei einem unbeaufsichtigten Fortsetzen nicht an, also verpassen Sie notwendige Erholung, wenn Sie sie auf die Letztere legen.

Auch Apps ohne Fenster können die Benachrichtigungen empfangen

Fensterlose Dienste und Konsolen-Apps können RegisterSuspendResumeNotification mit DEVICE_NOTIFY_CALLBACK nutzen und dieselben Benachrichtigungen über einen Callback empfangen.⁸

Außerdem kann WM_POWERBROADCAST nicht unterscheiden, ob der energiesparende Zustand Schlaf oder Ruhezustand war.⁷ Die App sollte ihre Erholung um das gemeinsame Ereignis „es hat gestoppt, und es ist zurückgekommen“ herum entwerfen.

3. Modern Standby — Die Bedeutung von „Schlaf“ hat sich geändert

Dass das System läuft und dass die App laufen kann, sind verschiedene Dinge

Der herkömmliche S3-Schlaf ist ein Modell, das das ganze System stoppt. Modern Standby dagegen ist ein smartphone-ähnliches Modell, in dem das System nach dem Ausschalten des Bildschirms intermittierend weiterläuft.

Das heißt jedoch nicht, dass gewöhnliche Desktop-Apps weiterlaufen. In der ersten Stufe des Schlafeintritts werden sie vom Desktop Activity Moderator (DAM) pausiert.³

Die Komponenten, die von der intermittierenden Aktivität profitieren, sind die, die für diesen Mechanismus gebaut sind. Für den Entwurf einer Geschäftsanwendung ist die Schlussfolgerung in beiden Fällen dieselbe: „der eigene Code läuft während des Schlafs nicht“.³

flowchart TB
    accTitle: Unterschied zwischen herkömmlichem Schlaf und Modern Standby
    accDescr: Herkömmlicher S3-Schlaf stoppt das ganze System, während unter Modern Standby das System nach dem Ausschalten des Bildschirms intermittierend weiterläuft. Desktop-Apps werden jedoch vom DAM pausiert, sodass der Code der App in beiden Fällen nicht läuft
    s3["Herkömmlicher S3-Schlaf: das ganze System stoppt"] --> conc["Der Code der App läuft nicht"]
    ms["Modern Standby: das System läuft intermittierend"] --> dam["Desktop-Apps werden vom DAM pausiert"]
    dam --> conc

Abbildung 4: Das Modell hat sich geändert, aber für eine Desktop-App ist die Schlussfolgerung dieselbe: „während des Schlafs können Sie nicht laufen“.

Machen Sie die Fortsetzungsbenachrichtigung nicht zur einzigen Bedingung der Erholung

Eintritt in den und Austritt aus dem energiesparenden Leerlauf von Modern Standby fallen nicht immer mit dem herkömmlichen Suspend-Übergang zusammen. Eine Verbindung kann bereits getrennt sein, ohne dass eine Benachrichtigung ankam. Behandeln Sie die Fortsetzungsbenachrichtigung als Hilfe, die die Erholung beschleunigt, und legen Sie einen Pfad, der bei erkanntem Kommunikationsfehler wiederverbindet, in die Mitte. Die konkrete Struktur erklärt Kapitel 5.

Außerdem ist der Übergang in den energiesparenden Zustand gestuft, sodass der Zeitpunkt von Trennungen und Stopps nicht so scharf ist wie unter S3. Auch Benutzer können „der Bildschirm ist nur aus“ und „es hat geschlafen“ schwer unterscheiden. Wenn Sie ein Symptom aufnehmen, prüfen Sie daher ob der Deckel geschlossen wurde und wie viele Minuten die Maschine im Leerlauf gelassen wurde.

4. Was kaputtgeht — Klassische Symptome

Fehler nach dem Fortsetzen lassen sich in Verbindungen, Geräte-Handles und die Kontinuität der Zeit gliedern. Bei gemeinsam genutzten Ressourcen prüfen Sie außerdem, wie lange erneute Authentifizierung und das Neuaufbauen des Netzes dauern.

Eine TCP-Verbindung merkt die Trennung erst beim Senden oder Empfangen

Während des Schlafs behandeln Gegenseite, NAT-Geräte und Firewalls Ihr Schweigen als Timeout und verwerfen die Verbindung. Der Socket auf dieser Seite weiß davon jedoch nichts, sodass er erst fehlschlägt, wenn Sie nach dem Fortsetzen senden oder empfangen.

Manchmal fehlerte ein ausstehendes Empfangen überhaupt nie. Deshalb brauchen Sie einen Keepalive, der prüft, ob die Verbindung lebt. Datenbankverbindungen und WebSockets folgen demselben Muster.

Serielle Schnittstellen und USB-Geräte brauchen neu geöffnete Handles

Ein USB-Gerät kann beim Fortsetzen so aussehen, als wäre es abgezogen und wieder eingesteckt worden, und das Handle, das offen war, beginnt Fehler zurückzugeben. Das ist das typische Muster hinter einer Gerätesteuerungs-App, die „nur nach der Mittagspause einen Kommunikationsfehler bekommt“.

Nehmen Sie nicht an, dass das Handle weiter nutzbar bleibt, sondern strukturieren Sie die App so, dass sie das Gerät neu öffnen kann. Wiederverbindungsentwurf behandelt auch der Artikel zur seriellen Kommunikation.

Periodische Arbeit, verstrichene Zeit und geplante Arbeit getrennt überdenken

Probleme mit der Zeit fallen in die folgenden drei Arten.

Gerade periodische Arbeit kann unmittelbar nach dem Fortsetzen einmal für den überfälligen Tick feuern, oder bis zur nächsten Periode geschieht nichts. Überlassen Sie den Umgang mit verpassten Läufen nicht dem impliziten Verhalten des Timers.

flowchart TB
    accTitle: Drei Formen, in denen die Kontinuität der Zeit bricht
    accDescr: Periodische Arbeit stoppt während des Schlafs und das Feuern nach dem Fortsetzen unterscheidet sich nach API, also bauen Sie den Zeitplan beim Fortsetzen neu auf; die Differenz zum vorherigen Zeitstempel wird nach dem Fortsetzen riesig, also schützen Sie sie; geplante Arbeit läuft nicht, wenn die Maschine schläft, also erwägen Sie das Aufwachen aus dem Schlaf der Aufgabenplanung
    t1["Periodische Arbeit: stoppt während des Schlafs"] -.-> g1["Zeitplan beim Fortsetzen neu aufbauen"]
    t2["Differenz der verstrichenen Zeit: explodiert"] -.-> g2["Abnorme Differenzen schützen"]
    t3["Geplante Arbeit: geschlafen, nie gelaufen"] -.-> g3["Mit einer Aufwacheinstellung aufwecken"]

Abbildung 5: Schreiben Sie Timer- und Uhrbehandlung unter der Annahme, dass „die Zeit springt“. Jede der drei Formen hat ihre eigene Art von Gegenmaßnahme.

flowchart TB
    accTitle: Drei Dinge, die über den Schlaf hinweg kaputtgehen
    accDescr: Über den Schlaf hinweg ist eine TCP-Verbindung durch ein Timeout auf der Gegenseite verworfen, das Handle eines USB-Geräts ist wie bei einer Wiederverbindung ungültig, und Arbeit auf Basis verstrichener Zeit beobachtet einen riesigen Zeitsprung. Stellen Sie jedes mit Wiederverbinden, Neuöffnen und einem Differenzschutz wieder her
    sleep["Schlafintervall"] --> tcp["TCP-Verbindung: auf der Gegenseite verworfen"]
    sleep --> usb["USB-Gerät: Handle ungültig"]
    sleep --> time["Verstrichene Zeit: ein riesiger Sprung"]
    tcp -.-> r1["Fehler erkennen und wiederverbinden"]
    usb -.-> r2["Gerät neu öffnen"]
    time -.-> r3["Abnorme Differenzen schützen"]

Abbildung 6: Was kaputtgeht, fällt in drei Familien — „Verbindungen“, „Handles“ und „Kontinuität der Zeit“ — und jede hat eine feststehende Art der Erholung.

Netzlaufwerke und VPNs haben unmittelbar nach dem Fortsetzen eine Wartezeit

Netzlaufwerke und VPNs brauchen nach dem Fortsetzen manchmal erneute Authentifizierung und Neuaufbau. Deshalb gibt es unmittelbar nach dem Fortsetzen ein Fenster von wenigen bis mehreren zehn Sekunden, in dem der Zugriff fehlschlägt.

Wiederholen Sie nicht alles auf einmal in dem Moment, in dem die Maschine fortsetzt, sondern entwerfen Sie die App so, dass sie ein wenig wartet und gestuft wiederholt.

5. Apps bauen, die das Fortsetzen überstehen

Das Prinzip ist, die App so zu strukturieren, dass sie sich jederzeit erholen kann, auch wenn Verbindungen und Handles den Schlaf nicht überleben. Entwerfen Sie Wiederverbindung, Zeitbehandlung und Schlafunterdrückung für die Intervalle, die sie brauchen, jeweils für sich.

Fortsetzungsbenachrichtigung und Kommunikationsfehler in dieselbe Wiederverbindungsarbeit münden lassen

Wenn das WM_POWERBROADCAST des Fensters der obersten Ebene PBT_APMRESUMEAUTOMATIC empfängt, verwerfen Sie die Verbindungen, die Sie halten, und bauen Sie sie neu auf. Verlassen Sie sich jedoch nicht allein auf die Fortsetzungsbenachrichtigung. Benachrichtigungen können verpasst werden, und Kommunikation kann stattfinden, bevor die Benachrichtigung ankommt.

Stellen Sie immer einen Pfad bereit, der „wiederverbindet, wenn ein Kommunikationsfehler erkannt wird“, und behandeln Sie die Fortsetzungsbenachrichtigung als Auslöser, der diese Arbeit früher startet. Das folgende C#-Beispiel ist der Teil, der von der Fortsetzungsbenachrichtigung aus eine Wiederverbindung anfordert. Die Seite der Kommunikationsfehler mündet in dieselbe Wiederverbindungsarbeit.

// C#: Fortsetzungsbenachrichtigung und Kommunikationsfehler in dieselbe Wiederverbindungsarbeit münden lassen
protected override void WndProc(ref Message m)
{
    const int WM_POWERBROADCAST = 0x0218;
    const int PBT_APMRESUMEAUTOMATIC = 0x0012;
    if (m.Msg == WM_POWERBROADCAST && (int)m.WParam == PBT_APMRESUMEAUTOMATIC)
    {
        _connectionManager.RequestReconnect();   // idempotente Wiederverbindungsanforderung
    }
    base.WndProc(ref m);
}

Wiederverbindung kombiniert „Idempotenz, Backoff und Keepalive“

Wiederverbindungsarbeit braucht die folgenden drei Elemente zusammen.

Dieses Dreier-Set hilft nicht nur beim Fortsetzen aus dem Schlaf, sondern ebenso bei kurzen Netzabbrüchen und Geräteneustarts.

flowchart TB
    accTitle: Wiederverbindungsentwurf, der das Fortsetzen übersteht
    accDescr: Die Fortsetzungsbenachrichtigung, ein Kommunikationsfehler und ein Keepalive-Fehlschlag münden alle in dieselbe idempotente Wiederverbindungsarbeit, die bei Fehlschlag mit exponentiellem Backoff wiederholt
    e1["Fortsetzungsbenachrichtigung (PBT_APMRESUMEAUTOMATIC)"] --> r["Idempotente Wiederverbindungsarbeit"]
    e2["Kommunikationsfehler erkannt"] --> r
    e3["Keepalive-Fehlschlag"] --> r
    r --> ok{"Gelungen?"}
    ok -->|"Ja"| run["Zurück in den Normalbetrieb"]
    ok -->|"Nein"| back["Nach exponentiellem Backoff wiederholen"]
    back --> r

Abbildung 7: Konzentrieren Sie Wiederverbindung in einen einzigen idempotenten Pfad, und betreten Sie dieselbe Straße von der Fortsetzungsbenachrichtigung, der Fehlererkennung oder dem Keepalive.

Mischen Sie ein Intervall, in dem die Zeit gesprungen ist, nicht in Ihre Berechnungen

Für Arbeit, die „verstrichene Zeit seit dem letzten Mal“ nutzt, setzen Sie einen Schutz ein, der das Intervall ungültig macht, wenn er eine abnormal große Differenz erkennt. Der Punkt ist, sie nicht in einen Durchschnitt zu falten und sie nicht als gewöhnliches Timeout zu behandeln.

Wenn Sie Zeit über das Fortsetzen hinweg messen, unterscheiden Sie die Uhr, die während des Schlafs weiterläuft (Wanduhrenzeit), von der tatsächlich für Arbeit aufgewendeten Zeit. Das Neuaufbauen des Zeitplans periodischer Arbeit und der Umgang mit geplanter Arbeit, die nicht gelaufen ist, sollten Sie ebenfalls anhand der Kategorien in Kapitel 4 überdenken.

Unterdrücken Sie den Schlaf ausdrücklich für Arbeit, die nicht unterbrochen werden darf

Während Arbeit läuft, die nicht verschlafen werden darf, etwa eine Datenmigration oder fortlaufende Kommunikation mit einem Gerät, nutzen Sie SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED). Wenn Sie auch die Anzeige anlassen wollen, fügen Sie ES_DISPLAY_REQUIRED hinzu.⁷⁴

Das andere Mittel ist eine Energieanforderung über PowerCreateRequest und PowerSetRequest. Weil Sie eine Begründungszeichenfolge anhängen können, zeigt powercfg /requests „wer den Schlaf blockiert, und warum“. Dieses Mittel ist freundlicher, weil der Betrieb die Begründung lesen kann.⁵

Das Setzen der Unterdrückung verhindert jedoch nicht jede Art von Unterbrechung. Prüfen Sie die folgenden Einschränkungen getrennt von der Erholungslogik.

flowchart TB
    accTitle: Zwei Mittel, den Schlaf zu unterdrücken
    accDescr: Ob Sie das bequeme SetThreadExecutionState oder die Energieanforderungs-API nutzen, die eine Begründungszeichenfolge anhängen kann und für einen Administrator über powercfg sichtbar ist — heben Sie sie immer auf, wenn die Arbeit endet
    need["Arbeitsintervall, das nicht verschlafen werden darf"] --> a["SetThreadExecutionState"]
    need --> b["Energieanforderung (PowerSetRequest)"]
    a -.-> a1["Bequem, nur Flags"]
    b -.-> b1["Mit Begründung, in powercfg sichtbar"]
    a --> off["Immer aufheben, wenn die Arbeit endet"]
    b --> off

Abbildung 8: Für beide Mittel ist „aufheben, wenn Sie fertig sind“ eine absolute Bedingung. Eine Energieanforderung, die die Begründung sichtbar machen kann, ist freundlicher zum Betrieb.

Wenn Dauerbetrieb eine Anforderung ist, überdenken Sie Platzierung und Betrieb

Dienste und fensterlose Apps können die Benachrichtigungen ebenfalls über DEVICE_NOTIFY_CALLBACK mit RegisterSuspendResumeNotification empfangen.⁸

Wenn Dauerbetrieb wirklich erforderlich ist, überdenken Sie jedoch, die Arbeit überhaupt auf einem Client-PC resident zu halten, der schläft. Die Arbeit auf die Serverseite oder auf eine Maschine zu verschieben, die ohne Schlaf betrieben wird, ist die grundlegende Lösung.

6. Untersuchung — powercfg und das Ereignisprotokoll

Bei einer Support-Anfrage prüfen Sie zuerst, ob der PC knapp vor dem Fehler geschlafen hat. Fragen Sie, ob der Deckel geschlossen wurde und wie viele Minuten die Maschine im Leerlauf gelassen wurde, und nutzen Sie dann das Werkzeug, das zum Symptom passt.

Wenn Sie das Ereignisprotokoll mit dem Log der App abgleichen, können Sie objektiv prüfen, ob knapp vor dem Fehler ein Fortsetzen war. Bleiben Sie nicht beim Verdacht auf Schlaf stehen; gleichen Sie die Zeitstempel ab und grenzen Sie die Ursache ein.

flowchart TB
    accTitle: Abbildung von Energieproblem-Symptomen auf Untersuchungsbefehle
    accDescr: Bei einem Symptom schläft-nicht finden Sie mit powercfg /requests, wer eine Energieanforderung hält; bei einem Symptom wacht-von-selbst-auf finden Sie den Aufwachgrund mit /lastwake und /waketimers; für die Zeitachse nutzen Sie Kernel-Power im Ereignisprotokoll
    s1["Es schläft nicht"] --> c1["powercfg /requests"]
    s2["Es wacht von selbst auf"] --> c2["powercfg /lastwake und /waketimers"]
    s3["Die Zeitachse prüfen wollen"] --> c3["Kernel-Power im Ereignisprotokoll"]
    c1 -.-> note["Eine nie aufgehobene Schlafunterdrückung taucht auch auf"]

Abbildung 9: Symptome bilden sich in drei Familien auf Untersuchungsbefehle ab. Prüfen Sie zuerst „hat es knapp vorher geschlafen“, dann wählen Sie das Werkzeug.

7. Zusammenfassung

Die Behandlung von Schlaf ist nicht fertig, nur weil Sie die Benachrichtigungen empfangen. Rechnen Sie damit, dass die Vorbereitung nicht rechtzeitig fertig wird und dass die Fortsetzungsbenachrichtigung nicht ankommt, und teilen Sie die Rollen wie folgt.

Aus Sicht der App ist Schlaf ein Ereignis, in dem „die Zeit ohne Vorwarnung springt, Verbindungen zur Umgebung gekappt werden und dann alles zurückkommt“. Ob der Entwurf das als Teil des Alltags behandelt und nicht als anomale Situation, ist das, was stabile Geschäftsanwendungen im Laptop-Zeitalter von instabilen trennt.

Weiterführende Artikel

• Fallstricke bei seriellen Kommunikationsanwendungen — von der Wiederverbindung bis zum Log-Design
• Windows-Herunterfahren aus Sicht Ihrer App — Beendigungsbenachrichtigungen, Neustarts und Stromverlust richtig überstehen
• Was ist der Windows-Effizienzmodus? - Das grüne Blattsymbol und wie Sie ihn deaktivieren
• Warum Sie unter Windows Ereigniswarten gegenüber Sleep(1) bevorzugen sollten
• Was „Keine Rückmeldung“ wirklich ist — Wie Windows entscheidet, dass eine App hängt, und Entwürfe, die nicht hängen

Zugehörige Beratungsfelder

KomuraSoft LLC übernimmt Ursachenuntersuchungen von Fehlern wie „die Kommunikation bricht nach dem Fortsetzen aus dem Schlaf“ und „die Verbindung zum Gerät fällt nach der Mittagspause ab“, das nachträgliche Einbauen von Wiederverbindungslogik und Energieereignisbehandlung in bestehende Apps sowie Entwurfsreviews von Geschäftsanwendungen und Gerätesteuerungssoftware, die für Laptop-Betrieb gebaut sind.

• Fehleruntersuchung und Ursachenanalyse
• Windows-Anwendungsentwicklung
• Technische Beratung und Design-Review
• Kontakt

Quellen

Verwandte Artikel

Aktuelle Artikel mit denselben Schlagwörtern führen zu verwandten Themen weiter.

Verwandte Themen

Diese Seiten ordnen den Artikel in einen größeren Leistungs- und Entscheidungskontext ein.

Leistungen zu diesem Thema

Dieser Artikel ist direkt mit den folgenden Leistungen verbunden.

Häufige Fragen

Fragen, die in Beratungen zu diesem Artikelthema häufig gestellt werden.

Kann eine App im Voraus erfahren, dass die Maschine schlafen will, und das ablehnen?

Unter aktuellem Windows kann eine App die Benachrichtigung empfangen, aber nicht ablehnen. Kurz vor dem Schlaf liefert eine WM_POWERBROADCAST-Nachricht das Ereignis PBT_APMSUSPEND; die App kann sich vorbereiten, indem sie Dateien schließt und den Zustand speichert, aber die erlaubte Verarbeitungszeit beträgt etwa 2 Sekunden pro App. Darüber hinaus macht das System ohne Warten weiter. Bei einem Notfall-Suspend, etwa bei fast leerem Akku, kommt gar keine Vorabbenachrichtigung. Ein Entwurf, der „vor dem Schlaf fertig sein muss“, hält daher nicht; der Entwurf muss einer sein, der sich beim Fortsetzen erholen kann, egal wann der Schnitt kommt. Für eine Arbeitsstrecke, die wirklich nicht verschlafen werden darf, unterdrücken Sie den Schlaf ausdrücklich mit SetThreadExecutionState oder einer Energieanforderung (PowerSetRequest).

Wie erkenne ich, dass die Maschine fortgesetzt hat?

Wenn die App ein Fenster hat, behandeln Sie WM_POWERBROADCAST. Beim Fortsetzen aus dem Suspend kommt PBT_APMRESUMEAUTOMATIC an, und wenn das Fortsetzen durch eine Benutzeraktion ausgelöst wurde (die Ein-/Aus-Taste oder ein Tastendruck), folgt PBT_APMRESUMESUSPEND. Ein unbeaufsichtigtes Fortsetzen, das sofort wieder schläft, liefert nur PBT_APMRESUMEAUTOMATIC. Die Grundaufteilung ist daher: notwendige Arbeit wie das Wiederverbinden auf die Seite von PBT_APMRESUMEAUTOMATIC legen, benutzerseitige Arbeit wie Bildschirmaktualisierungen auf die Seite von PBT_APMRESUMESUSPEND. Fensterlose Dienste und Konsolen-Apps können dieselben Benachrichtigungen über einen Callback empfangen, indem sie RegisterSuspendResumeNotification mit DEVICE_NOTIFY_CALLBACK verwenden.

Kann ich die App während des Schlafs weiterlaufen lassen?

In der Regel nein. Während des Schlafs stoppt die CPU-Ausführung selbst (auf einer Modern-Standby-Maschine werden Desktop-Apps vom Desktop Activity Moderator pausiert), und der Code der App läuft nicht. Es gibt zwei Möglichkeiten. Die eine ist, den Schlaf nur zu unterdrücken, solange die Arbeit läuft. Die Angabe von ES_SYSTEM_REQUIRED mit SetThreadExecutionState oder das Ausstellen einer Energieanforderung mit PowerCreateRequest/PowerSetRequest unterdrückt in diesem Intervall den automatischen Leerlaufschlaf (Sie können das mit powercfg /requests prüfen). Das stoppt trotzdem keine ausdrückliche Schlafaktion wie das Schließen des Deckels durch den Benutzer, also müssen Sie auch bei eingeschalteter Unterdrückung auf das Fortsetzen vorbereitet sein. Die andere ist, den Schlaf hinzunehmen und so zu entwerfen, dass die App „nach dem Fortsetzen aufholt“. Für geplante Arbeit wie einen nächtlichen Batch können Sie den PC auch mit der Funktion „Computer zum Ausführen dieser Aufgabe aktivieren“ der Aufgabenplanung aufwecken. Arbeit, die wirklich durchlaufen muss, gehört auf einen Server oder einen Dienst, der so konfiguriert ist, dass er nicht schläft.

Warum funktionieren TCP-Verbindungen und serielle Schnittstellen nach dem Fortsetzen nicht mehr?

Weil Netzadapter und USB-Geräte während des Schlafs ebenfalls in einen energiesparenden Zustand fallen. Die TCP-Verbindung ist auf der Gegenseite oder durch ein NAT- oder Firewall-Timeout bereits verworfen, sodass Senden und Empfangen nach dem Fortsetzen fehlschlagen (oft merken Sie es erst, wenn es fehlschlägt). USB-Seriell-Adapter und Ähnliches werden beim Fortsetzen manchmal als Geräteentfernung und Wiedereinsetzen behandelt, und das Handle, das offen war, wird ungültig. In beiden Fällen ist die richtige Annahme, dass „Handles und Verbindungen das Fortsetzen nicht überleben“, und die richtige Antwort ist Wiederverbindungslogik, die die Verbindung bei einer Fortsetzungsbenachrichtigung oder einem Kommunikationsfehler neu aufbaut. Das etablierte Muster kombiniert einen periodischen Keepalive mit Wiederholungen, die bei Fehlschlag exponentielles Backoff nutzen.

Wie untersuche ich eine Maschine, die von selbst schläft oder von selbst aufwacht?

Der Befehl powercfg ist das erste Werkzeug. In Richtung „es schläft nicht“ listet powercfg /requests, welche Prozesse und Treiber eine Energieanforderung ausgestellt haben, die den Schlaf blockiert. In Richtung „es wacht von selbst auf“ zeigt powercfg /lastwake den jüngsten Aufwachgrund und powercfg /waketimers die Timer, die derzeit reserviert sind, um die Maschine aufzuwecken. Auf einer Modern-Standby-Maschine erzeugt powercfg /sleepstudy einen Bericht über Verbrauch und Aktivität während des Schlafs. Schlaf- und Fortsetzungsgeschichte ist auch im Ereignisprotokoll festgehalten (die Quelle Kernel-Power im Systemprotokoll), sodass Sie auf einer Zeitachse prüfen können, wann die Maschine geschlafen hat und wann und warum sie aufgewacht ist.

Autorenprofil

Profilseite des Artikelautors.

Go Komura

Geschäftsführer von KomuraSoft LLC

Spezialisiert auf Windows-Softwareentwicklung, technische Beratung und Fehleranalyse, insbesondere bei bestehenden Systemen und schwer reproduzierbaren Störungen.