Energiesparmodus, Ruhezustand, Modern Standby und lang laufende Anwendungen ── Design gegen „über Nacht stehengeblieben“

„Ich war sicher, dass die Überwachungsanwendung die ganze Nacht gelaufen ist, aber als ich morgens nachsah, brach der Graph einfach um 1 Uhr nachts abrupt ab.“ „Das Erfassungstool lief monatelang absolut stabil auf einem Desktop-PC, doch sobald wir auf ein Notebook umgestiegen sind, tauchten Lücken in den Aufzeichnungen auf.“ — Von allen Symptomen, die in Beratungen zu lang laufenden Business-Anwendungen zur Sprache kommen, ist dies der Klassiker der Klassiker. Prüft man die Protokolle, findet sich keine Ausnahme, kein Absturz – nur mehrere Stunden an Aufzeichnungen, die vollständig fehlen. Weit häufiger als nicht liegt die Ursache gar nicht in einem Fehler der Anwendung selbst – es ist die Energieverwaltung von Windows.

Was das Ganze tückisch macht, ist, dass „Energiesparmodus“ gar nicht eine einzige Sache ist. Der klassische S3-Energiesparmodus, der Ruhezustand (S4) und Modern Standby (S0 Low Power Idle) – inzwischen die Norm bei neueren Notebooks – sehen aus Sicht einer Anwendung jeweils anders aus, sowohl darin, wie sie sie stoppen, als auch darin, welche Gegenmaßnahmen funktionieren. Insbesondere Modern Standby wird wegen seiner Vermarktung als „das System läuft auch während des Energiesparmodus weiter“ oft missverstanden, doch in Wirklichkeit werden Desktop-Anwendungen sogar noch aggressiver aktiv gestoppt als unter den älteren Modellen.

Dieser Artikel behandelt gerade so viel über die Arten des Energiesparmodus und das Verhalten einer Anwendung währenddessen, wie nötig ist, und arbeitet dann auf, wie man zwischen drei Designs wählt – den Energiesparmodus verhindern, um ihn herum designen und die Maschine zu einem festen Zeitpunkt aufwecken –, komplett mit Implementierungsbeispielen und einer Entscheidungstabelle.

1. Das Wichtigste zuerst

• Windows kennt drei Energiesparmodelle — den klassischen S3-Energiesparmodus, den Ruhezustand (S4) und Modern Standby (S0 Low Power Idle) —, und eine Modern-Standby-fähige Maschine unterstützt S1 bis S3 nicht. Welches davon Ihr PC verwendet, lässt sich mit powercfg /a prüfen.¹²³
• Desktop-Anwendungen laufen auch während Modern Standby nicht weiter. Der Desktop Activity Moderator (DAM) suspendiert die Threads von Desktop-Prozessen (Dienste in Sitzung 0 werden stattdessen gedrosselt). Gehen Sie beim Design nicht davon aus, dass „es S0 ist, also muss es weiterlaufen“.⁴
• Während des Energiesparmodus läuft kein Thread, und wie die Frist eines Timers gezählt wird, unterscheidet sich zudem je nach API-Generation. Seit Windows 8 zählen relative Timer und Wartevorgänge (die relative Form von SetWaitableTimer, SleepEx und Ähnliches) die im Energiesparmodus verbrachte Zeit nicht mit und tragen die verbleibende Dauer auf die Zeit nach der Reaktivierung über.⁵⁶ Die Timer von .NET sind bis einschließlich .NET 10 so implementiert, dass sie die Energiesparzeit mitzählen (läuft die Frist also während des Energiesparmodus ab, feuern sie unmittelbar nach der Reaktivierung), und ab .NET 11 wechseln sie dazu, sie nicht mehr mitzuzählen.⁶ APIs zur verstrichenen Zeit sind ebenfalls eine Mischung aus solchen, die die Energiesparzeit mitzählen (GetTickCount, QueryPerformanceCounter – die Grundlage von Stopwatch), und solchen, die sie nicht mitzählen (QueryUnbiasedInterruptTime).⁷⁸
• Eine TCP-Verbindung, die während des Energiesparmodus inaktiv wird, kann am Ende stillschweigend durch das Leerlauf-Timeout eines zwischengeschalteten Geräts verworfen werden – eines NAT, einer Firewall, eines Load Balancers (der Azure Load Balancer verwirft einen Datenfluss beispielsweise standardmäßig nach 4 Minuten ohne jede Benachrichtigung). Gehen Sie beim Design davon aus, dass Sie nach der Reaktivierung neu verbinden müssen.⁹⁴
• Der richtige Weg, den Energiesparmodus zu unterdrücken, ist SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED). Das betrifft jedoch nur den automatischen Wechsel durch ein Leerlauf-Timeout – es kann einen vom Benutzer ausdrücklich ausgelösten Wechsel per Netzschalter oder Zuklappen nicht verhindern. Setzen Sie es nur für den tatsächlich benötigten Abschnitt und löschen Sie es danach stets wieder.¹⁰¹¹
• Ob die Unterdrückung greift, lässt sich mit powercfg /requests bestätigen. Die PowerCreateRequest-Familie von APIs erlaubt es, der Anfrage einen Begründungstext beizufügen, der in dieser Auflistung erscheint – was die Untersuchung vor Ort erheblich erleichtert.¹²¹³¹⁴
• Designen Sie stattdessen um den Energiesparmodus herum, erkennen Sie ihn in .NET über SystemEvents.PowerModeChanged oder in Win32 über WM_POWERBROADCAST (PBT_APMSUSPEND / PBT_APMRESUMEAUTOMATIC). Die Karenzzeit für die Suspendierungsbenachrichtigung beträgt pro Anwendung nur etwa 2 Sekunden, und unter kritischen Akkubedingungen kann das System ganz ohne jede Benachrichtigung in den Energiesparmodus wechseln.^15161718
• Um etwas zuverlässig zu einem festen Zeitpunkt auszuführen, ist die Option „Computer zur Ausführung dieser Aufgabe reaktivieren“ (WakeToRun) der Aufgabenplanung die erste Wahl. Sie hält das System wach, bis die Aufgabe abgeschlossen ist. Sie hängt jedoch von der Reaktivierungstimer-Berechtigung in den Energieoptionen ab, sodass es unerlässlich ist, vor Ort zu verifizieren, dass die Maschine tatsächlich aufwacht.¹⁹²⁰

2. Der Windows-Energiesparmodus ist nicht eine einzige Sache

Beginnen wir mit nur den drei Zuständen, die Sie als Grundlage brauchen, bevor Sie über Gegenmaßnahmen nachdenken.

S3 und S4 sind beide „ein Zustand, in dem das System überhaupt keine Berechnung ausführt und dem äußeren Anschein nach ausgeschaltet wirkt“.¹ Modern Standby dagegen ist ein Modell, das näher am Energiemodell eines Smartphones liegt: Es wartet mit geringem Stromverbrauch weiter, hält die Netzwerkverbindung selbst bei ausgeschaltetem Bildschirm aufrecht und reaktiviert in unter einer Sekunde per Netzschalter. Maschinen, die Modern Standby unterstützen, verwenden S1 bis S3 nicht.²²¹

Wichtig ist hier der Desktop Activity Moderator (DAM), der auf Modern-Standby-fähigen Maschinen mitgeliefert wird. DAM ist der Mechanismus, der die Ausführung von Desktop-Anwendungen so weit herunterdrosselt, dass sie äquivalent zum S3-Energiesparmodus wird, wenn das System in den Standby wechselt: Prozesse in einer interaktiven Sitzung haben sämtliche ihrer Threads suspendiert, während Dienste in Sitzung 0 gedrosselt werden (die meiste Zeit suspendiert, nur zeitweise laufend).⁴ Mit anderen Worten: Die Erwartung, dass „Anwendungen während des Energiesparmodus weiterlaufen, weil es Modern Standby ist“, ist genau falsch herum – aus Sicht der Anwendung stoppt sie genauso wie unter S3 –, und anders als bei S3, weil „das System selbst läuft, während nur die Anwendung gestoppt ist“, ist es am sichersten, dies als etwas zu verstehen, das sich als Uhrenabweichung und inkonsistentes Timer-Verhalten zeigt.⁴

Sie können ohne Administratorrechte prüfen, welches Modell Ihr PC (oder der PC eines Kunden vor Ort) verwendet, mit folgendem Befehl.³

> powercfg /a
The following sleep states are available on this system:
    Standby (S0 Low Power Idle) Network Connected
    Hibernate
    ...

Zeigt sie Standby (S3), ist die Maschine eine S3-Maschine; zeigt sie S0 Low Power Idle, ist es eine Modern-Standby-Maschine. Immer wenn die Beschwerde lautet „Aufzeichnungen fielen aus, seit wir auf ein Notebook umgestiegen sind“, ist dies das Erste, was zu prüfen ist.

3. Was während des Energiesparmodus und nach der Reaktivierung mit einer Anwendung passiert

3.1 Threads und Timer

Während des Energiesparmodus (S3/S4 sowie während einer DAM-Suspendierung) wird kein Thread ausgeführt.¹⁴ Leicht zu übersehen ist, wie die „Frist“ eines Timers oder Wartevorgangs die Energiesparzeit zählt, und dies unterscheidet sich je nachdem, welche API-Ebene Sie verwenden.

• Ein relativer Win32-Timer (die relative Form von SetWaitableTimer / SetWaitableTimerEx) zählte unter Windows 7 und früher die im Energiesparzustand verbrachte Zeit mit (der Countdown lief auch während des Energiesparmodus weiter), tut dies aber unter Windows 8 und neuer nicht. Ein relativer Timer, der einen Energiesparmodus überspannt, feuert erst, nachdem die verbleibende Zeit nach der Reaktivierung abgewartet wurde.⁵
• Ebenso stoppen Wartevorgang-APIs mit Timeout (SleepEx, WaitForMultipleObjectsEx und Ähnliches) ab Windows 8 das Mitzählen nicht laufender Zeit wie des Energiesparmodus. Die verbleibende Zeit wird über den Energiesparmodus hinweg übertragen.⁶
• Wann ein verwalteter .NET-Timer (System.Threading.Timer und Ähnliches) feuert, hängt von der Laufzeitversion ab. Das liegt daran, dass Environment.TickCount64 bis einschließlich .NET 10 die Energiesparzeit einschließt (es basiert auf GetTickCount64) und ab .NET 11 aufhört, sie einzuschließen (Wechsel zu einer Grundlage aus QueryUnbiasedInterruptTime); die Änderungsdokumentation selbst warnt in der Folge davor, dass „es Code geben könnte, der den Timer nicht mehr unmittelbar nach der Reaktivierung feuert“.⁶

Mit anderen Worten: Wenn „eine Anwendung, die mit einem 10-Sekunden-System.Threading.Timer misst, 8 Stunden lang schläft“, wird sie in keinem Fall auf einmal 8 Stunden an Ticks nachholen – doch ob sie unmittelbar nach der Reaktivierung einmal feuert oder erst die verbleibende Zeit abwartet, hängt von der API-Ebene und der Laufzeitversion ab. So oder so gehen Stichproben während des Energiesparmodus verloren. Statt Ihre Wiederherstellungslogik darauf aufzubauen, dass „es unmittelbar nach der Reaktivierung feuert“, ist es sicherer, mithilfe des in Kapitel 5 behandelten Reaktivierungsereignisses explizit neu zu planen.

3.2 Die Messung verstrichener Zeit driftet

APIs zur verstrichenen Zeit sind eine Mischung aus solchen, die die Energiesparzeit einschließen, und solchen, die es nicht tun.

Code, der besagt „die nächste Stichprobe nehmen, sobald Stopwatch anzeigt, dass 10 Sekunden vergangen sind“, bedeutet am Ende, sobald er einen Energiesparmodus überspannt, „8 Stunden und 10 Sekunden sind vergangen“, und umgekehrt ändern TickCount-basierte Prüfungen der verstrichenen Zeit ihr Verhalten, sobald Sie zu .NET 11 wechseln. Eine klare Arbeitsteilung beizubehalten – Stopwatch für „wie lange ein Vorgang gedauert hat“ verwenden und DateTime/DateTimeOffset für „die Uhrzeit, zu der als Nächstes etwas laufen sollte“, und diese Grundlage beim Reaktivierungsereignis neu verankern (Kapitel 5) – bewahrt Sie davor, weder vom Energiesparmodus noch von einem Laufzeit-Upgrade überrascht zu werden. Das Design kurzperiodischer Timer selbst wird in Warum Sie unter Windows Event-Waits gegenüber Sleep(1) bevorzugen sollten behandelt.

3.3 Eine TCP-Verbindung stirbt „lautlos“

Während des Energiesparmodus kann die Anwendung nicht kommunizieren, sodass die Verbindung inaktiv wird. Das Problem liegt bei den Geräten auf dem Weg. Zwischengeschaltete Geräte wie NAT, Firewalls und Load Balancer verwerfen einen inaktiven Datenfluss aufgrund eines Timeouts, und in vielen Konfigurationen verwerfen sie ihn stillschweigend, ohne eine der beiden Seiten zu benachrichtigen. Das Standardverhalten des Azure Load Balancer beispielsweise besteht darin, „einen Datenfluss stillschweigend zu verwerfen, sobald er das Leerlauf-Timeout erreicht (standardmäßig 4 Minuten)“.⁹ Interne Büro-Router und die eingebetteten TCP-Stacks von Geräten im Feld tragen ähnliche Timeouts.

Als Ergebnis sieht der Socket der Anwendung unmittelbar nach der Reaktivierung völlig unauffällig aus, und dann bricht entweder das nächste Senden mit einem Fehler ab, oder es hängt beim Warten auf eine Antwort, bis es abläuft. Die Dokumentation von DAM selbst weist ausdrücklich darauf hin, dass Sie berücksichtigen müssen, wie sich die Prozesssuspendierung auf die Lebensdauer einer Verbindung und einen laufenden Handshake auswirkt.⁴ Zusätzlich wird auf einer akkubetriebenen Modern-Standby-Maschine die Netzwerkaktivität während des Energiesparmodus standardmäßig vollständig ruhiggestellt (Adaptive Connected Standby).²³ Die übliche Praxis besteht darin, die Verbindung als verdächtig zu behandeln und sie sofort nach Erhalt eines Reaktivierungsereignisses zu verwerfen/neu zu verbinden. Zur Diagnose einer Verbindung, die „lebendig aussieht, aber tatsächlich tot ist“, siehe auch Diagnose, warum TCP-Neuübertragung die Kommunikation einer Industriekamera blockiert.

4. Sicherstellen, dass kein Energiesparmodus eintritt — SetThreadExecutionState und Energieanforderungen

Wenn Sie sich den Energiesparmodus für die wenigen Stunden, in denen eine Messung läuft, nicht leisten können, ist SetThreadExecutionState das richtige Werkzeug. Rufen Sie es aus C# per P/Invoke auf.

using System.Runtime.InteropServices;

internal static class PowerGuard
{
    [Flags]
    private enum EXECUTION_STATE : uint
    {
        ES_CONTINUOUS       = 0x80000000,
        ES_SYSTEM_REQUIRED  = 0x00000001,
        ES_DISPLAY_REQUIRED = 0x00000002,
    }

    [DllImport("kernel32.dll", SetLastError = true)]
    private static extern EXECUTION_STATE SetThreadExecutionState(EXECUTION_STATE esFlags);

    /// <summary>Beim Beginn einer Messung aufrufen: unterdrückt den automatischen Energiesparmodus (vom selben Thread wie End aufrufen)</summary>
    public static void Begin() =>
        SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS |
                                EXECUTION_STATE.ES_SYSTEM_REQUIRED);

    /// <summary>Stets beim Ende einer Messung aufrufen: löscht die Unterdrückung (vom selben Thread wie Begin aufrufen)</summary>
    public static void End() =>
        SetThreadExecutionState(EXECUTION_STATE.ES_CONTINUOUS);
}

Hier die Details, die Sie im Kopf behalten müssen.

• Fügen Sie ES_CONTINUOUS hinzu, und der Effekt hält an, bis Sie es erneut mit gesetztem ES_CONTINUOUS aufrufen. Ohne dieses Flag setzt der Aufruf den Leerlauftimer nur einmalig zurück, möchten Sie also, dass es dauerhaft gilt, müssen Sie es periodisch wiederholt aufrufen.¹⁰
• ES_SYSTEM_REQUIRED unterdrückt den System-Energiesparmodus, und ES_DISPLAY_REQUIRED unterdrückt das Abschalten des Displays. Für eine Hintergrundmessung genügt Ersteres allein. ES_DISPLAY_REQUIRED zusätzlich zu setzen, wenn es in Ordnung ist, dass der Bildschirm dunkel wird, ist reine Energieverschwendung.¹⁰
• Es kann den Energiesparmodus, der durch Drücken des Netzschalters oder Zuklappen des Laptops durch den Benutzer ausgelöst wird, nicht verhindern. Diese Funktion betrifft nur den automatischen Wechsel durch ein Leerlauf-Timeout. Die offizielle Dokumentation stellt selbst unmissverständlich fest, dass eine ausdrückliche Handlung des Benutzers respektiert werden sollte.¹⁰
• Das System führt eine Zählung der Threads, die SetThreadExecutionState aufgerufen haben, und wechselt in den Energiesparmodus, sobald diese Zählung null erreicht und keine Benutzereingabe vorliegt.¹¹ Stirbt der Prozess unerwartet, verschwindet die Unterdrückung mit ihm, sodass Sie sich keine Sorgen machen müssen, mit „einem PC zu enden, der nie in den Energiesparmodus wechselt, weil jemand vergessen hat, die Unterdrückung zu löschen“ – im schlimmsten Fall löst ein Neustart es –, doch aus demselben Grund bietet dies keinerlei eigene Absturzresilienz: Stürzt der Prozess ab, verschwindet die von ihm bereitgestellte Unterdrückung des Energiesparmodus einfach mit ihm, und es bleibt nichts übrig, das eine noch laufende Messung schützt.
• Wie der Name schon sagt, setzt diese Funktion den Ausführungszustand des aufrufenden Threads.¹⁰ Setzen und löschen Sie es vom selben Thread. Da eine async/await-Fortsetzung auf einem anderen Thread-Pool-Thread laufen kann, kann eine Implementierung, die Begin() und End() über ein await hinweg aufruft, dazu führen, dass der löschende Aufruf auf einem anderen Thread landet als dem, der die Unterdrückung gesetzt hat – er verfehlt sie vollständig und lässt die Unterdrückung so lange bestehen, wie der ursprüngliche Thread am Leben bleibt. Es ist am sichersten, diese Aufrufe an einen Thread mit garantierter Identität zu binden, etwa den UI-Thread; erfordert Ihr Design das Überschreiten von Thread-Grenzen, verwenden Sie stattdessen die im Folgenden behandelte handle-basierte Power-Request-API.

Seit Windows 7 gibt es auch eine neuere API für denselben Zweck: Power Requests (PowerCreateRequest / PowerSetRequest / PowerClearRequest). Ihr praktischer Vorteil ist, dass Sie beim Erstellen der Anfrage über REASON_CONTEXT einen Begründungstext übergeben können; neben PowerRequestSystemRequired gehört zu den Anfragetypen auch PowerRequestExecutionRequired, das die Prozesssuspendierung auf einer Modern-Standby-Maschine unterdrückt.¹⁴¹³ Die offizielle Best Practice lautet „Set unmittelbar vor Beginn des Szenarios, Clear sobald es endet, und das Handle bereinigen, bevor der Prozess beendet wird“.¹³

Modern-Standby-Maschinen haben jedoch eine wichtige Einschränkung: Auf einem akkubetriebenen Modern-Standby-System werden SystemRequired-/ExecutionRequired-Anfragen 5 Minuten nach dem Zeitpunkt gekappt, zu dem das Energiesparmodus-Timeout andernfalls erreicht worden wäre. Und unabhängig von der Stromquelle endet eine Anfrage in dem Moment, in dem der Energiesparmodus durch eine Benutzeraktion ausgelöst wird – Netzschalter, Zuklappen oder Energiesparmodus über das Startmenü.¹³ Mit anderen Worten: „Auf einem Notebook weiterlaufen, selbst bei zugeklapptem Deckel, selbst im Akkubetrieb“ ist schlicht nichts, das eine Anwendung aus eigener Kraft erreichen kann. Eine solche Anforderung muss stattdessen über Energieeinstellungen und betriebliche Richtlinien sichergestellt werden – Einstellungen, die den Energiesparmodus beim Zuklappen verhindern, oder das Verbleiben am Netzstrom.

Sie können von einer erhöhten Eingabeaufforderung aus bestätigen, ob die Unterdrückung tatsächlich greift.

> powercfg /requests
SYSTEM:
[PROCESS] \Device\HarddiskVolume3\Apps\SensorLogger.exe

powercfg /requests ist ein Befehl, der die derzeit den Energiesparmodus oder das Abschalten des Displays blockierenden Energieanforderungen auflistet, und er ist sowohl zur Untersuchung eines „PC, der rätselhafterweise nie in den Energiesparmodus wechselt“ als auch zur Bestätigung der eigenen Unterdrückung Ihrer Anwendung nützlich.¹² Beachten Sie umgekehrt, dass ein Administrator mit powercfg /requestsoverride konfigurieren kann, dass die Anfragen eines bestimmten Prozesses ignoriert werden.¹² Die zugrunde liegende Designannahme ist, dass die Unterdrückungs-API eine „Anfrage“ ist, keine absolute Garantie.

Ein letztes Wort zu gutem Verhalten. Eine Implementierung, die ES_CONTINUOUS | ES_SYSTEM_REQUIRED für die gesamte Laufzeit der Anwendung gesetzt lässt, bedeutet, dass eine residente Anwendung dauerhaft den vom Benutzer eingerichteten Energiesparplan außer Kraft setzt. Auf einem Notebook entlädt das den Akku, und auf einem gemeinsam genutzten PC beeinträchtigt es auch andere Nutzungen der Maschine. Das Prinzip lautet, die Unterdrückung nur auf „das Fenster zu beschränken, in dem der Vorgang, der keinen Energiesparmodus verträgt, tatsächlich läuft“ (das eigene Beispiel der offiziellen Dokumentation lautet „setzen, wenn die Aufnahme beginnt, löschen, wenn die Aufnahme endet“¹⁰). Übrigens gibt es auch PowerToys Awake als temporären Workaround, den ein Benutzer selbst anwenden kann, und auch dieser läuft intern über denselben Mechanismus – ein Thread, der einen Ausführungszustand anfordert.²⁴ Das ist ebenfalls ein nützlicher Referenzpunkt, um zu entscheiden, wo die Grenze zwischen der Implementierung der Unterdrückung in der Anwendung und der Überlassung an ein Betriebswerkzeug zu ziehen ist.

5. Design um den Energiesparmodus herum — Erkennung, Neuverbindung und Aufzeichnung von Lücken

Für die meisten residenten Überwachungs- oder Erfassungsanwendungen erweist sich die Koexistenz mit dem Energiesparmodus als das solidere Design, statt ihn rundweg zu verbieten. Was Sie benötigen, sind drei Dinge: vorab wissen, dass er eintritt, wissen, wann er endet, und den Zustand nach der Reaktivierung wieder aufbauen.

In .NET ist Microsoft.Win32.SystemEvents.PowerModeChanged der Einstiegspunkt.¹⁵

using Microsoft.Win32;

SystemEvents.PowerModeChanged += OnPowerModeChanged;

private void OnPowerModeChanged(object sender, PowerModeChangedEventArgs e)
{
    switch (e.Mode)
    {
        case PowerModes.Suspend:
            // Die Karenzzeit ist kurz: hier nur Puffer leeren und den Zeitpunkt aufzeichnen, zu dem die Messung stoppte
            _logger.Info("suspend at {0:O}", DateTimeOffset.Now);
            _collector.Pause();
            break;

        case PowerModes.Resume:
            // 1) Die Lücke selbst als Daten aufzeichnen
            _logger.Info("resume at {0:O}", DateTimeOffset.Now);
            // 2) Davon ausgehen, dass die Verbindung tot ist, sie verwerfen und neu verbinden
            _connection.Reset();
            // 3) Den Zeitplan gegen die Wanduhr neu berechnen und Timer neu scharf schalten
            _scheduler.Rebase(DateTimeOffset.Now);
            // 4) Die Erfassung erst nach abgeschlossenem Wiederaufbau ausdrücklich fortsetzen (nicht pausiert lassen)
            _collector.Resume();
            break;
    }
}

Die offizielle Dokumentation weist auf zwei Vorbehalte zu diesem Ereignis hin: Es feuert nur, wenn eine Message Pump läuft (ein Windows-Dienst benötigt dafür so etwas wie eine versteckte Form), und da es ein statisches Ereignis ist, führt das Versäumnis, es abzumelden, zu einem Leck.¹⁵ Eine GUI-Anwendung kann es einfach direkt nutzen, doch für eine Konsolen- oder dienstartige Erfassungsanwendung müssen Sie entweder ein eigenes Nachrichtenfenster einrichten, um Win32s WM_POWERBROADCAST zu empfangen, oder PowerRegisterSuspendResumeNotification verwenden, das einen Callback ganz ohne HWND empfangen kann (dies ist auch der Weg, den Benachrichtigungen in einer DAM-Umgebung nehmen).⁴¹⁶

Behandeln wir auch, was die Ereignisse auf Win32-Ebene tatsächlich bedeuten.

• PBT_APMSUSPEND: Benachrichtigung unmittelbar vor dem Energiesparmodus. Es gibt nur etwa 2 Sekunden Karenzzeit pro Anwendung, und deren Überschreiten kann dazu führen, dass Sie vom System abgeschnitten werden. Beschränken Sie hier Ihre Tätigkeit auf das Leeren von Puffern und das Aufzeichnen des Zeitpunkts – schreiben Sie niemals etwas Zeitaufwendiges, etwa eine Bereinigung über das Netzwerk.¹⁷¹⁸
• PBT_APMRESUMEAUTOMATIC: eine Benachrichtigung, die garantiert bei jeder einzelnen Reaktivierung eintrifft. Platzieren Sie hier Ihre Neuverbindungs- und Neuplanungslogik.²⁵
• PBT_APMRESUMESUSPEND: trifft nach PBT_APMRESUMEAUTOMATIC ein, wenn die Reaktivierung durch eine Benutzeraktion erfolgt (oder sobald der Benutzer zurückkehrt). Es trifft bei einer automatischen Reaktivierung wie einem Remote-Wake nicht ein, sodass eine unbeaufsichtigte Reaktivierung den Wiederaufbau nie auslöst, wenn Sie Ihre „Reaktivierungsbehandlung“ ausschließlich hier platzieren.²⁶
• Darüber hinaus gibt es für einen kritischen Energiesparmodus – etwa einen bevorstehenden Akku-Abbruch – überhaupt keine vorherige Benachrichtigung.¹⁸ Schreiben Sie Ihre Reaktivierungsbehandlung idempotent, damit sie auch in einem Fall korrekt funktioniert, in dem Sie überhaupt nie ein Suspendierungsereignis erhalten haben.

Es gibt noch etwas, das genauso wichtig ist wie die Reaktivierungsbehandlung selbst: eine Lücke ausdrücklich als Lücke aufzuzeichnen. Erfassungsdaten, die einen Energiesparmodus überspannen, sind nicht „ein fehlender Wert“ – sie sind „nicht gemessen, weil das System gestoppt war“ –, und wenn Sie dieses Intervall zusammen mit den Suspendierungs-/Reaktivierungszeitstempeln sowohl im Protokoll als auch in den Daten selbst festhalten, wird niemand, der sich später die leere Stelle im Graphen ansieht, sie mit einem tatsächlichen Ausfall verwechseln. Was die Protokolle einer lang laufenden Anwendung erfassen sollten, wird ebenfalls in Untersuchung eines lang laufenden Absturzes einer Industriekamera — der Fall des Handle-Lecks behandelt.

Übrigens gibt es noch ein weiteres „Sie haben es nicht bemerkt, aber es wurde langsam“-Problem aus derselben Familie wie der Energiesparmodus: die Drosselung durch den Effizienzmodus (EcoQoS) von Windows 11. Siehe dazu Was ist der Windows-Effizienzmodus? - Das grüne Blattsymbol und wie Sie ihn deaktivieren.

6. Sicherstellen, dass etwas zu einem festen Zeitpunkt läuft — Aufwecken und Ausführen über die Aufgabenplanung

Einen zeitgesteuerten Job zu implementieren – etwas wie „um 2 Uhr nachts aggregieren und übertragen“ – mit dem Timer einer residenten Anwendung plus Unterdrückung des Energiesparmodus umzusetzen, ist ein schlechter Ansatz, da es bedeutet, den Energiesparmodus für die ganze Nacht abzuschalten. Für diesen Anwendungsfall ist die Option „Computer zur Ausführung dieser Aufgabe reaktivieren“ (WakeToRun) der Aufgabenplanung die eigentliche Antwort.

Eine Aufgabe mit aktiviertem WakeToRun weckt den Computer zum geplanten Zeitpunkt aus dem Energiesparmodus oder Ruhezustand auf und hält das System wach, bis die Aufgabe abgeschlossen ist (war er bereits wach, fordert sie ebenso an, dass das System bis zum Abschluss wach bleibt). Der Bildschirm kann beim Aufwachen ausgeschaltet bleiben – das ist normal.¹⁹

Es gibt jedoch Bedingungen, damit dieses Aufwachen tatsächlich stattfindet. Wie die offizielle Fehlerbehebungsanleitung darauf hinweist, hängt dies davon ab, dass „Reaktivierungstimer zulassen“ in den Energieoptionen aktiviert ist und die Aufwecken-Einstellung auf BIOS-Seite ebenfalls aktiviert ist, und es ist keineswegs ungewöhnlich, dass neuere Notebooks aus Gründen des Energiesparens so konfiguriert sind, dass ein Aufwachen überhaupt nicht zugelassen wird.²⁰ powercfg /waketimers kann die derzeit aktiven Reaktivierungstimer auflisten,¹² daher verifizieren Sie stets auf der tatsächlich eingesetzten Hardware, dass sie wirklich aufwacht. Möchten Sie die Maschine aus Ihrer eigenen Anwendung heraus aufwecken, gibt es auch die Option eines aufweckfähigen Timers – die Übergabe von TRUE für fResume bei SetWaitableTimer. In diesem Fall bleibt das System nach einem automatischen Aufwachen nur für die Dauer des unbeaufsichtigten Leerlauftimers wach (mindestens 2 Minuten) und kehrt umgehend in den Energiesparmodus zurück, sofern sich die Anwendung nicht per SetThreadExecutionState als „in Benutzung“ deklariert. Dauert die Arbeit nach dem Aufwachen länger, ist die korrekte Kombination, sie mit der Unterdrückung aus Kapitel 4 zu koppeln.²⁷

Betriebliche Designfragen wie das Konto, unter dem eine Aufgabe läuft, das Problem „endet mit 0x1“ und die Verhinderung mehrfacher gleichzeitiger Läufe werden in Aufgaben der Aufgabenplanung, die nicht laufen oder mit 0x1 enden — Diagnose und ein sicheres Betriebsdesign behandelt.

7. Eine Entscheidungstabelle — Unterdrücken, um die Reaktivierung herum designen oder aufwecken

Die drei Designs schließen sich nicht gegenseitig aus – Sie wählen für jeden Anwendungstyp einen primären und einen unterstützenden Ansatz und kombinieren sie.

Es gibt zwei Achsen für die Entscheidung: „Gibt es ein Zeitfenster, in dem es in Ordnung ist, dass es gestoppt ist?“ (falls ja, Aufgabenplanung; falls nein, Energieeinstellungen) und „Auf wessen PC läuft es?“ (je mehr eine Anwendung auf dem persönlichen oder gemeinsam genutzten Notebook eines Benutzers läuft, desto mehr sollten Sie sich zum Design um die Reaktivierung herum statt zur Unterdrückung neigen).

8. Zusammenfassung

• Der Energiesparmodus gibt es in den Formen S3, Ruhezustand (S4) und Modern Standby (S0 Low Power Idle), und Sie können sie mit powercfg /a unterscheiden. Selbst auf einer Modern-Standby-Maschine werden Desktop-Anwendungen vom DAM suspendiert, sodass die Annahme, dass „es während des Energiesparmodus weiterläuft“, nicht zutrifft.
• Weder Threads noch Timer schreiten während des Energiesparmodus voran. Seit Windows 8 zählen relative Timer und Wartevorgänge die Energiesparzeit nicht mit und tragen den Rest über, und die Timer von .NET verhalten sich ab .NET 11 ebenso (bis einschließlich .NET 10 können sie unmittelbar nach der Reaktivierung feuern). APIs zur verstrichenen Zeit sind eine Mischung aus solchen, die die Energiesparzeit mitzählen, und solchen, die es nicht tun. Verfolgen Sie verstrichene Zeit mit Stopwatch und die Wanduhrzeit mit DateTime, und verankern Sie Ihre Grundlage bei der Reaktivierung neu.
• Eine TCP-Verbindung stirbt beim Leerlauf-Timeout eines zwischengeschalteten Geräts lautlos. Die übliche Praxis besteht darin, beim Reaktivierungsereignis zu verwerfen und neu zu verbinden.
• Unterdrücken Sie mit SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED), begrenzt auf nur das benötigte Fenster. Es kann einen vom Benutzer ausgelösten Energiesparmodus nicht verhindern, und auf einer akkubetriebenen Modern-Standby-Maschine wird es nach 5 Minuten gekappt. Bestätigen Sie es mit powercfg /requests.
• Behandeln Sie die Reaktivierung mit SystemEvents.PowerModeChanged / WM_POWERBROADCAST. Da die Karenzzeit der Suspendierungsbenachrichtigung nur etwa 2 Sekunden beträgt und der Energiesparmodus auch ganz ohne jede Benachrichtigung eintreten kann, schreiben Sie die Reaktivierungsseite idempotent und zeichnen Sie das Lückenintervall auf.
• Um zu einem festen Zeitpunkt zu laufen, ist WakeToRun der Aufgabenplanung die eigentliche Antwort. Gestalten Sie es so, dass es sowohl die Reaktivierungstimer-Energieeinstellung als auch die Verifikation des Aufwachens auf der tatsächlichen Hardware einschließt.

Verwandte Artikel

• Aufgaben der Aufgabenplanung, die nicht laufen oder mit 0x1 enden — Diagnose und ein sicheres Betriebsdesign
• Warum Sie unter Windows Event-Waits gegenüber Sleep(1) bevorzugen sollten
• Diagnose, warum TCP-Neuübertragung die Kommunikation einer Industriekamera blockiert
• Untersuchung eines lang laufenden Absturzes einer Industriekamera — der Fall des Handle-Lecks
• Was ist der Windows-Effizienzmodus? - Das grüne Blattsymbol und wie Sie ihn deaktivieren

Verwandte Beratungsleistungen

Komura Software LLC übernimmt Design und Implementierung lang laufender Windows-Anwendungen für Messung, Überwachung und Datenerfassung sowie die Untersuchung von Fehlern, die speziell bei Dauerbetrieb auftreten, wie „über Nacht stehengeblieben“ oder „die Aufzeichnungen haben Lücken“. Kontaktieren Sie uns gerne auch zur Diagnose schwer reproduzierbarer Symptome im Zusammenhang mit Energiesparmodus und Energieverwaltung.

• Windows-App-Entwicklung
• Fehleranalyse und Ursachenermittlung
• Technische Beratung und Design-Review
• Kontakt

Referenzlinks

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.

Wie verhindere ich, dass der PC in den Energiesparmodus wechselt, nur solange meine Anwendung läuft?

Der Grundansatz besteht darin, beim Beginn des Vorgangs SetThreadExecutionState(ES_CONTINUOUS | ES_SYSTEM_REQUIRED) aufzurufen und es bei dessen Ende mit SetThreadExecutionState(ES_CONTINUOUS) wieder zu löschen. Fügen Sie ES_DISPLAY_REQUIRED nur hinzu, wenn Sie zusätzlich den Bildschirm eingeschaltet halten müssen. Das betrifft nur den automatischen Wechsel in den Energiesparmodus durch ein Leerlauf-Timeout – es kann einen vom Benutzer ausdrücklich ausgelösten Wechsel, etwa durch Drücken des Netzschalters oder Zuklappen des Laptops, nicht verhindern. Ob die Unterdrückung tatsächlich greift, lässt sich mit powercfg /requests bestätigen.

Was ist Modern Standby, und wie unterscheidet es sich vom klassischen Energiesparmodus?

Es handelt sich um ein neueres Energiesparmodell, auch S0 Low Power Idle genannt, bei dem das System teilweise mit geringem Stromverbrauch weiterläuft und sofort reaktiviert werden kann. Eine Modern-Standby-fähige Maschine unterstützt den klassischen S3-Energiesparzustand nicht. Allerdings bleibt nur Aktivität, die das Betriebssystem ausdrücklich erlaubt hat, tatsächlich „laufend“ – Desktop-Anwendungen werden mit sämtlichen Threads vom Desktop Activity Moderator (DAM) suspendiert, sodass sie aus Sicht der Anwendung genauso stoppen wie unter S3. Welchen Modus Ihr PC verwendet, lässt sich mit powercfg /a prüfen.

Warum funktioniert eine TCP-Verbindung nach der Reaktivierung aus dem Energiesparmodus nicht mehr?

Weil die Anwendung während des Energiesparmodus nicht kommunizieren kann, wird die Verbindung inaktiv, und zwischengeschaltete Geräte auf dem Weg – NAT, Firewalls, Load Balancer – verwerfen den Datenfluss aufgrund eines Leerlauf-Timeouts. Viele Geräte tun dies stillschweigend, ohne eine der beiden Seiten zu benachrichtigen, sodass der Socket der Anwendung bis zum ersten Senden oder Empfangen nach der Reaktivierung völlig unauffällig aussieht – und dann entweder sofort mit einem Fehler abbricht oder hängen bleibt, bis die Wartezeit auf eine Antwort abläuft. Die übliche Praxis besteht darin, die Verbindung als verdächtig zu behandeln und sie sofort nach Erhalt eines Reaktivierungsereignisses neu aufzubauen.

Ist für einen zuverlässigen nächtlichen Batch-Job die Unterdrückung des Energiesparmodus oder die Aufgabenplanung die bessere Wahl?

Die Option „Computer zur Ausführung dieser Aufgabe reaktivieren“ (WakeToRun) der Aufgabenplanung ist die erste Wahl. Sie weckt den PC zum geplanten Zeitpunkt und hält ihn wach, bis die Aufgabe abgeschlossen ist, sodass Sie nie den Energiesparmodus für die ganze Nacht abschalten müssen. Allerdings weckt sie den PC nicht auf, wenn Reaktivierungstimer in den Energieoptionen deaktiviert sind, sodass Sie bestätigen müssen, dass „Reaktivierungstimer zulassen“ aktiviert ist, und auf der tatsächlichen Hardware verifizieren müssen, dass sie wirklich aufwacht. Den Energiesparmodus durchgehend zu unterdrücken, verschwendet die ganze Zeit über Energie und läuft auf ein schlecht gestaltetes Design hinaus, das die eigenen Energieeinstellungen des Benutzers außer Kraft setzt.

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.