Windows Anwendung verhindert Energiesparmodus

Es gibt viele Anwendungsfälle, bei denen der Windows-Rechner trotz fehlender Nutzeraktivität nach einiger Zeit nicht in den Energiesparmodus schalten soll. Den Energiesparmodus in den Systemeinstellungen komplett auszuschalten ist umständlich, wenn man ihn später wieder einschalten möchte oder Energieverschwendung, wenn man ihn dauerhaft ausschaltet. Hierfür gibt es intelligentere Möglichkeiten: Eine Windows Anwendung kann den Energiesparmodus unterdrücken, solange sie läuft oder auch nur vorübergehend, ohne dass die Systemeinstellungen verändert werden müssen.

Das erwartet Sie im folgenden Blog-Beitrag:

Warum es hilfreich ist, den Energiesparmodus vorübergehend inaktiv zu setzen

Es gibt zahlreiche Anwendungsfälle, bei denen der Windows-Rechner nicht in den Energiesparmodus schalten soll, wenn es einige Zeit keine Benutzeraktivitäten gibt. Geht es dabei um eine 24/7 Verfügbarkeit des Rechners, muss das in den Energiesparoptionen konfiguriert werden.

Für alle anderen Anwendungsfälle ist das pauschale Abschalten des Energiesparmodus oft nicht die ideale Lösung. Meistens soll der Energiesparmodus nur vorübergehend verhindert werden, um zum Beispiel einen längeren Download oder Upload durchzuführen, ein Backup anzufertigen oder einen anderen länger laufenden Batchjob auszuführen, beispielsweise die Konvertierung von Videos. Nachdem diese Aufgabe abgeschlossen ist, soll der Rechner bei Benutzerinaktivität durchaus wieder in den Energiesparmodus schalten. Das spart nicht nur Geld, sondern schont auch die Umwelt: Bei einer Leerlaufleistung von 50W und 24/7 Betrieb beträgt der Energiebedarf immerhin 438 kWh/a. Da 50W Leerlaufleistung optimistisch sind (abhängig von Grafikkarte, Monitor etc.), sind der Energiebedarf und damit auch die Kosten wahrscheinlich deutlich höher. Nicht zuletzt kommt es häufiger vor, dass ein Windows Update die Energiesparoptionen wieder auf die Standardwerte zurücksetzt.

Es ist also aus verschiedenen Gründen besser, wenn die betreffende Anwendung selbst den Zeitraum bestimmt, in dem der Energiesparmodus verhindert werden soll oder dazu ein spezielles Werkzeug gestartet wird, das dies sicherstellt, falls die Anwendung das selbst nicht kann. Es gibt beispielsweise Werkzeuge, die kontinuierlich Mausbewegungen des Anwenders simulieren. Wenn es jedoch ausschließlich darum geht, den Energiesparmodus zu unterdrücken, dann geht das wesentlich einfacher mit Hilfe der Windows System Services, die eine Anwendung nutzen kann.

Den Energiesparmodus mit Windows System Services SetThreadExecutionState verhindern

Die Windows System Services stellen die Systemfunktion SetThreadExecutionState(…) bereit. Damit kann eine Anwendung dem System mitteilen, dass es benutzt wird und nicht in den Energiesparmodus wechseln oder der Bildschirm nicht ausgeschaltet werden soll:

C/C++

				
					EXECUTION_STATE SetThreadExecutionState(
  [in] EXECUTION_STATE esFlags
);
				
			

Damit eine Anwendung den Energiesparmodus verhindert, muss sie einmalig

				
					SetThreadExecutionState(ES_CONTINUOUS| ES_SYSTEM_REQUIRED)
				
			

rufen.

Wenn die Anwendung den Energiesparmodus nicht mehr verhindern soll, dann wird das Flag mit

				
					SetThreadExecutionState(ES_CONTINUOUS)
				
			

wieder gelöscht.

SetThreadExecutionState(…) kann allerdings nicht verhindern, dass der Anwender den Energiesparmodus interaktiv aktiviert. Das ist beispielsweise bei einem Notebook sinnvoll, das im Akkubetrieb läuft, wenn der Benutzer den Bildschirm zuklappt.

Vorübergehendes Abschalten des Energiesparmodus mit .Net C# – ein Beispiel

In .Net steht diese Funktion der Windows System Services leider nicht direkt zur Verfügung. Jedoch kann man dies mit der entsprechenden PInvoke-Schnittstelle lösen.

C#

				
					using System.Runtime.InteropServices;
...
    internal static class NativeMethods
    {
        [DllImport("kernel32.dll")]
        public static extern uint SetThreadExecutionState(EXECUTION_STATE esFlags);

        [FlagsAttribute]
        public enum EXECUTION_STATE : uint
        {
            ES_AWAYMODE_REQUIRED = 0x00000040,
            ES_CONTINUOUS = 0x80000000,
            ES_DISPLAY_REQUIRED = 0x00000002,
            ES_SYSTEM_REQUIRED = 0x00000001
            // Legacy flag, should not be used.
            // ES_USER_PRESENT = 0x00000004
        }
    }
				
			

Die Verwendung ist dann unkompliziert:

C#

				
					public class JobThatRequiresSystem
{
    ...
    private void ProhibitSleep()
    {
        var result =
            NativeMethods.SetThreadExecutionState(NativeMethods.EXECUTION_STATE.ES_CONTINUOUS | 
            NativeMethods.EXECUTION_STATE.ES_SYSTEM_REQUIRED);
        if (result == 0)
        {
            // handle error ...
        }
    }

    private void AllowSleep()
    {
        var result = NativeMethods.SetThreadExecutionState(NativeMethods.EXECUTION_STATE.ES_CONTINUOUS);
        if (result == 0)
        {
            // handle error ...
        }
    }

    public void RunJob()
    {
        ProhibitSleep();
        try
        {
            // do the job ...
        }
        finally
        {
            AllowSleep();
        }
    }
}
				
			

Wie man einen Fehler beim Aufruf von SetThreadExecutionState(…) behandelt, hängt stark von der Anwendung ab. Wenn das Unterdrücken des Energiesparmodus essenziell ist, zum Beispiel bei einem Backup, dann muss die Anwendung evtl. mit der entsprechenden Fehlermeldung beendet werden. In anderen Fällen kann das anders behandelt werden. Deshalb stellt der oben gezeigte Code auch nur eine Skizze dar.

Auf dieser Basis kann man beispielsweise eine App schreiben, die für eine bestimmte Zeit den Energiesparmodus unterdrückt. Der Benutzer kann die Zeit wie bei einer Eieruhr einstellen oder per Button beispielsweise 10-Minuten-Intervalle hinzufügen. Damit kann der Benutzer den Energiesparmodus vorübergehend unterdrücken, aber nicht vergessen, ihn wieder zu erlauben.
Eine Backupanwendung oder einen Service, der im 24/7 Betrieb läuft, würde man dagegen von vorneherein so erstellen, dass dieser selbst den Energiesparmodus, wie oben skizziert, steuert.

Wie man am enum EXECUTION_STATE erkennt, gibt es noch einige andere interessante Optionen. Einzelheiten dazu findet man in der Dokumentation von SetThreadExecutionState(…).

Die System Services stellen auch andere interessante Funktionen zur Verfügung, wie zum Beispiel GetSystemPowerStatus(…) oder SetSystemPowerStatus(…). Letzteres ist in gewisser Weise das Gegenteil von SetThreadExecutionState(…) und nur mit Bedacht zu verwenden.

Fazit

Durch den Systemaufruf SetThreadExecutionState(…) kann eine Anwendung verhindern, dass der PC bei Benutzerinaktivität in den Energiesparmodus wechselt und mit entsprechenden Parametern es am Ende wieder erlauben. Dieses Vorgehen ist flexibler und v.a. energie- und kostensparender als den Energiesparmodus in den Systemeinstellungen komplett auszuschalten. In .Net / C# kann man diese Systemfunktion leicht durch die entsprechende PInvoke-Schnittstelle nutzen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Mehr zu diesem Thema

Meine Top 5 Visual Studio Code Extensions

Visual Studio Code ist eine der meist verbreiteten IDEs, da sie kostenlos, einfach zu nutzen und personalisierbar durch Extensions ist.

Dabei gibt es so viele Extensions, dass man leicht den Überblick verliert. Einige lohnen sich aber für einen zweiten Blick und vielleicht sogar für eine Installation. Sie können den Entwickler-Alltag entspannter, fehlerfreier und manchmal bunter machen.

Deshalb liste ich heute meine Top 5 Visual Studio Code Extensions auf – vielleicht findet der eine oder andere auch etwas Nützliches für sich selbst darunter.

Weiterlesen »

Software-Migration 2: Leichter Brandgeruch - Frühsignale, konkrete Migrationsgründe und Feuerwehrsituationen in Altsystemen

Auch Altsysteme wollen gepflegt sein – davon war schon in einem vorangegangenen Beitrag die Rede. Selbst dann, wenn die Funktionalität nicht mehr erweitert wird, zwingen die Obsoleszenz von Hardwarekomponenten, und, ja, auch von Softwarekomponenten sowie erkannte Fehler und Sicherheitslücken in der eigenen Software dazu, in den Code des Systems einzugreifen.

Das kann ganz einfach sein oder auch verblüffend schwierig. Meist ist es beides, wie bei anspruchsvollen Sportarten: es ist einfach, bis man es wirklich tut und dann wird es schwierig. „Aber unser Herr Meyer, der kriegt das hin, der kennt sich mit dem System aus. Ach so, der geht in Rente? Ja dann wird‘s wirklich schwierig.“

Nun stellt sich die Frage, warum Änderungen in Altsystemen oftmals eine besondere Herausforderung darstellen.

Weiterlesen »

Analyse und Technologieauswahl bei der Software Migration

Im Fokus steht die Software Migration eines Altsystems – einer über 20 Jahre alten gewachsenen C# .NET Windows Forms-Anwendung – in eine Webanwendung. Die Anwendung selbst enthält einen großen Logik-Anteil, in den viel Entwicklungs- und Testaufwand investiert wurde. Ziel ist es, diesen Logikanteil weiterzuverwenden, um damit Ressourcen (Softwareentwicklungskosten und –zeit) zu sparen. Als Entwicklungspartner für Software stellen wir in diesem Artikel eine systematische Analyse und Technologieauswahl beispielhaft dar. Zudem stellen wir einige relevanten Frameworks und Technologien vor.

Weiterlesen »