Diensttriggerereignisse

Ein Dienst kann sich registrieren, um gestartet oder beendet zu werden, wenn ein Triggerereignis auftritt. Dadurch müssen Dienste nicht mehr gestartet werden, wenn das System gestartet wird, oder Dienste müssen ein Ereignis abfragen oder aktiv auf ein Ereignis warten. Ein Dienst kann gestartet werden, wenn er benötigt wird, anstatt automatisch zu starten, unabhängig davon, ob arbeite oder nicht. Beispiele für vordefinierte Triggerereignisse sind das Eintreffen eines Geräts einer angegebenen Geräteschnittstellenklasse oder die Verfügbarkeit eines bestimmten Firewallports. Ein Dienst kann sich auch für ein benutzerdefiniertes Triggerereignis registrieren, das von einem ETW-Anbieter ( Event Tracing for Windows ) generiert wird.

Windows Server 2008, Windows Vista, Windows Server 2003 und Windows XP: Diensttriggerereignisse werden erst unter Windows Server 2008 R2 und Windows 7 unterstützt.

Ein Trigger besteht aus einem Triggerereignistyp, einem Triggerereignisuntertyp, der Aktion, die als Reaktion auf das Triggerereignis ausgeführt werden soll, und (für bestimmte Triggerereignistypen) einem oder mehreren triggerspezifischen Datenelementen. Der Untertyp und die triggerspezifischen Datenelemente geben zusammen die Bedingungen für die Benachrichtigung des Diensts über das Ereignis an. Das Format eines Datenelements hängt vom Triggerereignistyp ab. Ein Datenelement kann Binärdaten, eine Zeichenfolge oder eine Multizeichenfolge sein. Zeichenfolgen müssen Unicode sein; ANSI-Zeichenfolgen werden nicht unterstützt.

Um sich für Triggerereignisse zu registrieren, ruft der Dienst ChangeServiceConfig2 mit SERVICE_CONFIG_TRIGGER_INFO auf und stellt eine SERVICE_TRIGGER_INFO-Struktur bereit. Die SERVICE_TRIGGER_INFO-Struktur verweist auf ein Array von SERVICE_TRIGGER Strukturen, die jeweils einen Trigger angeben.

Die angegebene Triggeraktion wird ausgeführt, wenn die Triggerbedingung true ist, wenn das System gestartet wird, oder wenn die Triggerbedingung true wird, während das System ausgeführt wird. Wenn sich beispielsweise ein Dienst registriert, um gestartet zu werden, wenn ein bestimmtes Gerät verfügbar ist, wird der Dienst gestartet, wenn das System gestartet wird, wenn das Gerät bereits an den Computer angeschlossen ist. Der Dienst wird gestartet, wenn das Gerät eintrifft, wenn der Benutzer das Gerät ansteckt, während das System ausgeführt wird.

Wenn ein Trigger über triggerspezifische Datenelemente verfügt, wird die Triggeraktion nur ausgeführt, wenn das Datenelement, das das Triggerereignis begleitet, mit einem der Datenelemente übereinstimmt, die vom Dienst mit dem Trigger angegeben wurden. Der Binäre Datenabgleich erfolgt durch einen bitweisen Vergleich. Beim Zeichenfolgenabgleich wird die Groß-/Kleinschreibung nicht beachtet. Wenn das Datenelement ein Multistring ist, müssen alle Zeichenfolgen in der Multizeichenfolge übereinstimmen.

Wenn ein Dienst als Reaktion auf ein Triggerereignis gestartet wird, empfängt der Dienst SERVICE_TRIGGER_STARTED_ARGUMENT als argv[1] in seiner ServiceMain-Rückruffunktion . Argv[0] ist immer der Kurzname des Diensts.

Ein Dienst, der sich registriert, um als Reaktion auf ein Triggerereignis gestartet zu werden, kann sich nach einem Leerlauftimeout selbst beenden, wenn der Dienst keine Arbeit zu erledigen hat. Ein Dienst, der sich selbst beendet, muss bereit sein, SERVICE_CONTROL_TRIGGEREVENT Steuerungsanforderungen zu verarbeiten, die eingehen, während der Dienst selbst beendet wird. Der SCM sendet eine SERVICE_CONTROL_TRIGGEREVENT-Steuerungsanforderung, wenn ein neues Triggerereignis auftritt, während sich der Dienst im ausgeführten Zustand befindet. Um den Verlust von Triggerereignissen zu vermeiden, sollte der Dienst ERROR_SHUTDOWN_IN_PROGRESS für jede SERVICE_CONTROL_TRIGGEREVENT-Steuerungsanforderung zurückgeben, die eingeht, während der Dienst von ausgeführt zu beendet wechselt. Dadurch wird der SCM angewiesen, Triggerereignisse in die Warteschlange zu stellen und zu warten, bis der Dienst in den Beendet-Zustand wechselt. Der SCM führt dann die Aktion aus, die dem Triggerereignis in der Warteschlange zugeordnet ist, z. B. das Starten des Diensts.

Wenn der Dienst bereit ist, Triggerereignisse erneut zu verarbeiten, legt er SERVICE_ACCEPT_TRIGGEREVENT in seiner akzeptierten Steuerelementmaske in einem Aufruf von SetServiceStatus fest. Dies erfolgt in der Regel, wenn der Dienst SetServiceStatus mit SERVICE_RUNNING aufruft. Der SCM gibt dann eine SERVICE_CONTROL_TRIGGEREVENT-Anforderung für jedes Triggerereignis in der Warteschlange aus, bis die Warteschlange leer ist.

Ein Dienst, für den abhängige Dienste ausgeführt werden, kann nicht als Reaktion auf ein Triggerereignis beendet werden.

Trigger-Start- und Trigger-Stop-Anforderungen sind bei geringem Arbeitsspeicher nicht garantiert.

Verwenden Sie die QueryServiceConfig2-Funktion , um die Triggerereigniskonfiguration eines Diensts abzurufen.

Das SC-Tool (sc.exe) kann verwendet werden, um die Triggerereignisse eines Diensts an der Eingabeaufforderung zu konfigurieren oder abzufragen. Verwenden Sie die Triggerinfo-Option , um einen Dienst so zu konfigurieren, dass er als Reaktion auf ein Triggerereignis gestartet oder beendet wird. Verwenden Sie die Option qtriggerinfo , um die Triggerkonfiguration eines Diensts abzufragen.

Im folgenden Beispiel wird die Triggerkonfiguration des W32time-Diensts abfragt, der so konfiguriert ist, dass er gestartet wird, wenn der Computer einer Domäne angehört und beendet wird, wenn der Computer die Domäne verlässt.

C:\>sc qtriggerinfo w32time
[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: w32time

        START SERVICE
          DOMAIN JOINED STATUS         : 1ce20aba-9851-4421-9430-1ddeb766e809 [DOMAIN JOINED]
        STOP SERVICE
          DOMAIN JOINED STATUS         : ddaf516e-58c2-4866-9574-c3b615d42ea1 [NOT DOMAIN JOINED]

Im folgenden Beispiel wird die Triggerkonfiguration des Tablet-Eingabediensts abgefragt, der so konfiguriert ist, dass ein HID-Gerät mit der GUID {4d1e55b2-f16f-11cf-88cb-0011111000030} und einer der angegebenen HID-Geräte-IDs eintrifft.

C:\>sc qtriggerinfo tabletinputservice
[SC] QueryServiceConfig2 SUCCESS

SERVICE_NAME: tabletinputservice

        START SERVICE
          DEVICE INTERFACE ARRIVAL     : 4d1e55b2-f16f-11cf-88cb-001111000030 [INTERFACE CLASS GUID]
            DATA                       : HID_DEVICE_UP:000D_U:0001
            DATA                       : HID_DEVICE_UP:000D_U:0002
            DATA                       : HID_DEVICE_UP:000D_U:0003
            DATA                       : HID_DEVICE_UP:000D_U:0004