Diensttriggerereignisse

Ein Dienst kann sich registrieren, um gestartet oder angehalten zu werden, wenn ein Triggerereignis auftritt. Dies beseitigt die Notwendigkeit, dass Dienste gestartet werden müssen, wenn das System gestartet wird, oder dienste, um ein Ereignis abzufragen oder aktiv zu warten; Ein Dienst kann gestartet werden, wenn er benötigt wird, anstatt automatisch zu starten, ob es arbeite. 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 Event Tracing for Windows (ETW)-Anbieter generiert wird.

Windows Server 2008, Windows Vista, Windows Server 2003 und Windows XP: Ereignisse zum Auslösen von Diensten werden erst unterstützt, wenn Windows Server 2008 R2 und Windows 7 ausgeführt werden.

Ein Trigger besteht aus einem Triggerereignistyp, einem Triggerereignisuntertyp, der als Reaktion auf das Triggerereignis auszuführenden Aktion und (für bestimmte Triggerereignistypen) ein oder mehrere triggerspezifische Datenelemente. Der Untertyp und die triggerspezifischen Datenelemente geben zusammen die Bedingungen für die Benachrichtigung des Diensts des Ereignisses 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 während der Ausführung des Systems wahr wird. Wenn beispielsweise ein Dienst registriert wird, der gestartet wird, 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 eingeht, wenn der Benutzer das Gerät anbindet, während das System ausgeführt wird.

Wenn ein Trigger triggerspezifische Datenelemente enthält, wird die Triggeraktion nur ausgeführt, wenn das Datenelement, das das Triggerereignis begleitet, mit einem der Datenelemente übereinstimmt, die der Dienst mit dem Trigger angegeben hat. Der Binäre Datenabgleich erfolgt im bitweisen Vergleich. Bei Zeichenfolgenabgleich wird die Groß-/Kleinschreibung nicht beachtet. Wenn es sich bei dem Datenelement um eine mehrfache Zeichenfolge handelt, 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 kurze Name des Diensts.

Ein Dienst, der als Reaktion auf ein Triggerereignis registriert wird, kann sich nach einem Leerlauftimeout beenden, wenn der Dienst keine Arbeit zu erledigen hat. Ein Dienst, der anhält, muss darauf vorbereitet sein, SERVICE_CONTROL_TRIGGEREVENT Steueranforderungen zu verarbeiten, die eingehen, während der Dienst beendet wird. Das SCM sendet eine SERVICE_CONTROL_TRIGGEREVENT Steuerelementanforderung, wenn ein neues Triggerereignis auftritt, während sich der Dienst im ausgeführten Zustand befindet. Um zu vermeiden, dass Triggerereignisse verloren gehen, sollte der Dienst ERROR_SHUTDOWN_IN_PROGRESS für jede SERVICE_CONTROL_TRIGGEREVENT Steuerelementanforderung zurückgeben, die eingeht, während der Dienst von der Ausführung zum Beenden wechselt. Dadurch wird der SCM angewiesen, Ereignisse in der Warteschlange auszulösen, und warten, bis der Dienst in den Angehaltenen Zustand wechselt. Der SCM führt dann die Aktion aus, die dem Auslösenereignis 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 der von Steuerelementen akzeptierten Maske in einem Aufruf von SetServiceStatus-fest. Dies geschieht in der Regel, wenn der Dienst SetServiceStatus- mit SERVICE_RUNNINGaufruft. Der SCM gibt dann eine SERVICE_CONTROL_TRIGGEREVENT Anforderung für jedes Ereignis in der Warteschlange aus, bis die Warteschlange leer ist.

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

Triggerstart- und Trigger-Stop-Anforderungen sind unter geringen Arbeitsspeicherbedingungen nicht garantiert.

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

Das SC-Tool (sc.exe) kann zum Konfigurieren oder Abfragen der Triggerereignisse eines Diensts an der Eingabeaufforderung verwendet werden. Verwenden Sie die Option triggerinfo, 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.

Das folgende Beispiel fragt die Triggerkonfiguration des W32time-Diensts ab, der so konfiguriert ist, dass er gestartet wird, wenn der Computer einer Domäne beigetreten ist, und beendet, 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-00111100030} und einer der angegebenen HID-Geräte-IDs eingeht.

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