Treiberpaketisolation

Die Isolierung von Treiberpaketen ist eine Voraussetzung für Windows-Treiber, die dafür sorgt, dass Treiberpakete resilienter gegenüber externen Änderungen, einfacher zu aktualisieren und unkomplizierter zu installieren sind.

Die folgende Tabelle zeigt in der linken Spalte einige Beispiele für veraltete Pakete, die für Windows-Treiber nicht mehr zugelassen sind, und in der rechten Spalte das erforderliche Verhalten für Windows-Treiber.

Hilfe bei der Feststellung, ob Ihr Treiberpaket die Anforderungen an die Isolierung von Treiberpaketen erfüllt, finden Sie unter Validierung von Windows-Treibern. Beispiele dafür, wie Sie eine INF aktualisieren können, um die Anforderungen an die Isolierung des Treiberpakets zu erfüllen, finden Sie unter Portieren einer INF, um die Isolierung des Treiberpakets zu gewährleisten.

Ausführen aus dem Treiber-Store

Alle isolierten Treiberpakete lassen ihre Treiberpaketdateien im Treiber-Store. Das bedeutet, dass sie DIRID 13 in ihrer INF angeben, um den Speicherort für die Dateien des Treiberpakets bei der Installation festzulegen. Weitere Informationen darüber, wie Sie dies in einem Treiberpaket verwenden, finden Sie unter Aus dem Store ausführen.

Lesen und Schreiben des Status

Der Zugriff auf verschiedene Registrierungs- und Dateistatus sollte durch den Aufruf von Funktionen erfolgen, die dem Aufrufer den Speicherort des Status mitteilen. Der Status wird dann relativ zu diesem Speicherort gelesen/geschrieben. Verwenden Sie keine fest kodierten absoluten Registrierungs- und Dateipfade.

Dieser Abschnitt enthält die folgenden Unterabschnitte:

• Registrierungsstatus

• Dateistatus

• Eigenschaftsstatus

Registrierungsstatus

Dieser Abschnitt enthält die folgenden Unterabschnitte:

• Registrierungsstatus von PnP-Geräten

• Registrierungsstatus von Geräteschnittstellen

• Registrierungsstatus von Diensten

Registrierungsstatus von PnP-Geräten

Isolierte Treiberpakete und Komponenten für den Benutzermodus verwenden in der Regel einen von zwei Orten, um den Status des Geräts in der Registrierung zu speichern. Dies sind der Hardwareschlüssel (Geräteschlüssel) für das Gerät und der Softwareschlüssel (Treiberschlüssel) für das Gerät. Der Hardwareschlüssel ist in der Regel für Einstellungen vorgesehen, die sich darauf beziehen, wie eine einzelne Instanz des Geräts mit der Hardware interagiert. Zum Beispiel, um eine Funktion der Hardware zu aktivieren oder die Hardware in einen bestimmten Modus zu versetzen. Der Softwareschlüssel dient in der Regel für Einstellungen, die sich darauf beziehen, wie eine einzelne Instanz des Geräts mit dem System und anderer Software interagiert. Zum Beispiel, um den Speicherort einer Datendatei festzulegen, um mit einem Framework zu interagieren oder um auf App-Einstellungen für ein Gerät zuzugreifen. Verwenden Sie eine der folgenden Optionen, um ein Handle zu diesen Speicherorten der Registrierung zu erhalten:

• IoOpenDeviceRegistryKey (WDM)

• WdfDeviceOpenRegistryKey, WdfFdoInitOpenRegistryKey (WDF)

• CM_Open_DevNode_Key (user-mode code)

• INF AddReg-Direktive unter Verwendung von HKR reg-root Einträgen in einem add-registry-section, der von einem INF DDInstall-Abschnitt oder DDInstall.HW-Abschnitt referenziert wird, wie unten gezeigt:

[ExampleDDInstall.HW]
AddReg = Example_DDInstall.AddReg

[Example_DDInstall.AddReg] 
HKR,,ExampleValue,,%13%\ExampleFile.dll

Registrierungsstatus von Geräteschnittstellen

Um den Registrierungsstatus der Geräteschnittstelle zu lesen und zu schreiben, verwenden Sie eine der folgenden Optionen:

• IoOpenDeviceInterfaceRegistryKey (WDM)

• CM_Open_Device_Interface_Key (user-mode code)

• INF AddReg-Direktive mit HKR reg-root-Einträgen in einem Add-registry-section, der von einem add-interface-section referenziert wird

Registrierungsstatus von Diensten

Der Status eines Dienstes sollte in eine von 3 Kategorien eingeteilt werden

• Nicht veränderbarer Registrierungsstatus des Dienstes

• Interner Registrierungsstatus des Dienstes

• Gemeinsamer Registrierungsstatus des Dienstes

Nicht veränderbarer Registrierungsstatus des Dienstes

Der unveränderliche Status des Dienstes ist der Status, der vom Treiberpaket, das den Dienst installiert, bereitgestellt wird. Diese Registrierungswerte, die von der INF für Treiber- und Win32-Dienste festgelegt werden, müssen unter dem Unterschlüssel „Parameter“ des Dienstes gespeichert werden, indem Sie eine HKR-Zeile in einem AddReg-Abschnitt bereitstellen und dann auf diesen Abschnitt im Dienstinstallationsabschnitt in der INF verweisen. Zum Beispiel:

[ExampleDDInstall.Services]
Addservice = ExampleService, 0x2, Example_Service_Inst

[Example_Service_Inst]
DisplayName    = %ExampleService.SvcDesc%
ServiceType    = 1
StartType      = 3
ErrorControl   = 1
ServiceBinary  = %13%\ExampleService.sys
AddReg=Example_Service_Inst.AddReg

[Example_Service_Inst.AddReg]
HKR, Parameters, ExampleValue, 0x00010001, 1

Um vom Dienst aus zur Laufzeit auf den Speicherort dieses Status zuzugreifen, verwenden Sie eine dieser Funktionen:

• IoOpenDriverRegistryKey (WDM) mit einem DRIVER_REGKEY_TYPE von DriverRegKeyParameters

• WdfDriverOpenParametersRegistryKey (WDF)

• GetServiceRegistryStateKey (Win32-Dienste) mit einem SERVICE_REGISTRY_STATE_TYPE von ServiceRegistryStateParameters

Diese von der INF im Unterschlüssel „Parameter“ für den Dienst bereitgestellten Registrierungswerte sollten nur zur Laufzeit gelesen und nicht verändert werden. Sie sollten als schreibgeschützt behandelt werden.

Wenn es sich bei den von der INF gelieferten Registrierungswerten um Standardeinstellungen handelt, die zur Laufzeit überschrieben werden können, sollten die überschreibenden Werte in den internen Registrierungsstatus des Dienstes oder gemeinsamen Registrierungsstatus des Dienstes geschrieben werden. Beim Abrufen der Einstellungen kann die Einstellung zunächst im veränderbaren Status gesucht werden. Wenn sie dort nicht vorhanden ist, kann die Einstellung im unveränderlichen Status gesucht werden. RtlQueryRegistryValueWithFallback kann verwendet werden, um Einstellungen wie diese abzufragen, die eine Überschreibung und einen Standardwert haben.

Interner Registrierungsstatus des Dienstes

Der interne Status eines Dienstes ist ein Status, der zur Laufzeit geschrieben wird und nur dem Dienst selbst gehört und verwaltet wird und nur für diesen Dienst zugänglich ist. Um auf den Speicherort für den internen Status des Dienstes zuzugreifen, verwenden Sie eine der folgenden Funktionen des Dienstes:

• IoOpenDriverRegistryKey (WDM) mit einem DRIVER_REGKEY_TYPE von DriverRegKeyPersistentState

• WdfDriverOpenPersistentStateRegistryKey (WDF)

• GetServiceRegistryStateKey (Win32-Dienste) mit einem SERVICE_REGISTRY_STATE_TYPE von ServiceRegistryStatePersistent

Wenn der Dienst anderen Komponenten die Möglichkeit bieten will, diese Einstellungen zu ändern, muss der Dienst eine Schnittstelle bereitstellen, die eine andere Komponente aufrufen kann und die dem Dienst mitteilt, wie er diese Einstellungen ändern kann. Ein Win32-Dienst könnte zum Beispiel eine COM- oder RPC-Schnittstelle und ein Treiberdienst eine IOCTL-Schnittstelle über eine Geräteschnittstelle bereitstellen.

Gemeinsamer Registrierungsstatus des Dienstes

Der gemeinsame Status eines Dienstes ist ein Status, der zur Laufzeit geschrieben wird und mit anderen Komponenten im Benutzermodus geteilt werden kann, wenn diese ausreichend privilegiert sind. Um auf den Speicherort für diesen gemeinsamen Dienststatus zuzugreifen, verwenden Sie eine dieser Funktionen:

• IoOpenDriverRegistryKey (WDM) mit einem DRIVER_REGKEY_TYPE von DriverRegKeySharedPersistentState

• GetSharedServiceRegistryStateKey (Win32-Dienste) mit einem SERVICE_SHARED_REGISTRY_STATE_TYPE von ServiceSharedRegistryPersistentState

Dateistatus

Dieser Abschnitt enthält die folgenden Unterabschnitte:

• Status der Gerätedatei

• Status der Servicedatei

• DriverData und ProgramData

• Temporäre Dateien

Status der Gerätedatei

Wenn Dateien, die sich auf ein Gerät beziehen, zur Laufzeit geschrieben werden müssen, sollten diese Dateien relativ zu einem Handle oder Dateipfad gespeichert werden, der über die APIs des Betriebssystems bereitgestellt wird. Ein Beispiel für Dateien, die hier gespeichert werden sollten, sind gerätespezifische Konfigurationsdateien. Um auf den Speicherort dieses Status zuzugreifen, verwenden Sie eine der folgenden Funktionen des Dienstes:

• IoGetDeviceDirectory (WDM) mit dem Parameter DirectoryType festgelegt auf DeviceDirectoryData

• WdfDeviceRetrieveDeviceDirectoryString (WDF)

Status der Servicedatei

Der Status der Servicedatei kann in eine von 3 Kategorien eingeteilt werden

• Nicht veränderbarer Status der Servicedatei

• Interner Status der Servicedatei

• Gemeinsamer Status der Servicedatei

Nicht veränderbarer Status der Servicedatei

Unveränderliche Status der Servicedatei sind Dateien, die Teil des Treiberpakets sind. Weitere Informationen zum Zugriff auf diese Dateien finden Sie unter Ausführen aus dem Treiber-Store.

Interner Status der Servicedatei

Ein interner Status der Servicedatei ist ein Status, der zur Laufzeit geschrieben wird und nur dem Dienst selbst gehört und verwaltet wird und auf den nur dieser Dienst Zugriff hat. Um auf den Speicherort für den internen Status des Dienstes zuzugreifen, verwenden Sie eine der folgenden Funktionen des Dienstes:

• IoGetDriverDirectory (WDM, KMDF) mit dem Parameter DirectoryType festgelegt auf DriverDirectoryData

• WdfDriverRetrieveDriverDataDirectoryString (UMDF)

• GetServiceDirectory (Win32-Dienste) mit dem Parameter eDirectoryType festgelegt auf ServiceDirectoryPersistentState

Wenn der Dienst anderen Komponenten die Möglichkeit bieten will, diese Einstellungen zu ändern, muss der Dienst eine Schnittstelle bereitstellen, die eine andere Komponente aufrufen kann und die dem Dienst mitteilt, wie er diese Einstellungen ändern kann. Ein Win32-Dienst könnte zum Beispiel eine COM- oder RPC-Schnittstelle und ein Treiberdienst eine IOCTL-Schnittstelle über eine Geräteschnittstelle bereitstellen.

Gemeinsamer Status der Servicedatei

Der Status der gemeinsam genutzten Status der Servicedatei ist ein Status, der zur Laufzeit geschrieben wird und mit anderen Komponenten im Benutzermodus geteilt werden kann, wenn diese ausreichend privilegiert sind. Um auf den Speicherort für diesen gemeinsamen Dienststatus zuzugreifen, verwenden Sie eine dieser Funktionen:

• IoGetDriverDirectory (WDM, KMDF) mit dem Parameter DirectoryType festgelegt auf DriverDirectorySharedData

• GetSharedServiceDirectory (Win32-Dienste), wobei der Parameter DirectoryType auf ServiceSharedDirectoryPersistentState festgelegt ist

DriverData und ProgramData

Dateien, die mit anderen Komponenten gemeinsam genutzt werden können, aber nicht in die Kategorie Gemeinsamer Status der Servicedatei passen, können entweder an DriverData- oder ProgramData-Speicherorte geschrieben werden.

Diese Speicherorte bieten Komponenten einen Ort, an dem sie temporäre Zustände oder Zustände schreiben können, die von anderen Komponenten verbraucht und möglicherweise von einem System gesammelt und kopiert werden sollen, um von einem anderen System verarbeitet zu werden. Dies gilt zum Beispiel für angepasste Log-Dateien oder Crash Dumps.

Vermeiden Sie das Schreiben von Dateien im Root der Verzeichnisse DriverData oder ProgramData. Erstellen Sie stattdessen ein Unterverzeichnis mit Ihrem Firmennamen und schreiben Sie dann Dateien und weitere Unterverzeichnisse in dieses Verzeichnis.

Bei einem Firmennamen wie Contoso könnte zum Beispiel ein Kernel-Mode-Treiber eine angepasste Log-Datei nach \DriverData\Contoso\Logs schreiben und eine User-Mode-Anwendung könnte die Log-Dateien aus %DriverData%\Contoso\Logs sammeln oder analysieren.

DriverData

Das Verzeichnis DriverData steht in Windows 10 ab Version 1803 zur Verfügung und ist für Administrator*innen und UMDF-Treiber zugreifbar.

Treiber im Kernel-Modus greifen auf das Verzeichnis DriverData über einen vom System bereitgestellten symbolischen Link namens \DriverData zu.

Benutzer*innen greifen auf das Verzeichnis DriverData mit Hilfe der Umgebungsvariablen %DriverData% zu.

ProgramData

Die Umgebungsvariable %ProgramData% für den Benutzermodus steht den Komponenten des Benutzermodus für das Speichern von Daten zur Verfügung.

Temporäre Dateien

Temporäre Dateien werden in der Regel für Zwischenvorgänge verwendet. Diese können in einen Unterpfad unter den Umgebungsvariablen %TEMP% oder %TMP% geschrieben werden. Da der Zugriff auf diese Speicherorte über Umgebungsvariablen erfolgt, ist diese Möglichkeit auf Komponenten im Benutzermodus beschränkt. Es gibt keine Garantien für die Lebensdauer oder das Fortbestehen dieser temporären Dateien, nachdem Handles auf sie geschlossen wurden. Das Betriebssystem oder der Benutzer*innen können sie jederzeit löschen und sie bleiben möglicherweise nicht über einen Neustart hinaus bestehen.

Vermeiden Sie das Schreiben von Dateien im Root der Verzeichnisse %TEMP% oder %TMP%. Erstellen Sie stattdessen ein Unterverzeichnis mit Ihrem Firmennamen und schreiben Sie dann Dateien und weitere Unterverzeichnisse in dieses Verzeichnis.

Eigenschaftsstatus

Sowohl Geräte als auch Geräteschnittstellen unterstützen das Speichern des Status über das PnP-Eigenschaftsmodell. Das Eigenschaftsmodell bietet die Möglichkeit, strukturierte Eigenschaftsdaten für ein Gerät oder eine Geräteschnittstelle zu speichern. Dies ist für kleinere Daten gedacht, die vernünftigerweise in die vom Eigenschaftsmodell unterstützten Eigenschaftstypen passen.

Für den Zugriff auf Geräteeigenschaften können diese APIs verwendet werden:

• WDM-Treiber

  • IoGetDevicePropertyData

  • IoSetDevicePropertyData

• WDF-Treiber

  • WdfDeviceQueryProperty

  • WdfDeviceAllocAndQueryProperty

  • WdfDeviceQueryPropertyEx

  • WdfDeviceAllocAndQueryPropertyEx

  • WdfDeviceAssignProperty

  • WdfFdoInitQueryProperty

  • WdfFdoInitAllocAndQueryProperty

  • WdfFdoInitQueryPropertyEx

  • WdfFdoInitAllocAndQueryPropertyEx

• Benutzermodus-Code

  • CM_Get_DevNode_Property

  • CM_Set_DevNode_Property

Für den Zugriff auf Eigenschaften von Geräteschnittstellen können diese APIs verwendet werden:

• WDM-Treiber

  • IoGetDeviceInterfacePropertyData

  • IoSetDeviceInterfacePropertyData

• WDF-Treiber

  • WdfDeviceQueryInterfaceProperty

  • WdfDeviceAllocAndQueryInterfaceProperty

  • WdfDeviceAssignInterfaceProperty

• Benutzermodus-Code

  • CM_Get_Device_Interface_Property

  • CM_Set_Device_Interface_Property

Verwenden von Geräteschnittstellen

Wenn ein Treiber anderen Komponenten die Möglichkeit bieten möchte, den internen Status des Treibers zu lesen oder zu ändern, sollte der Treiber eine Schnittstelle bereitstellen, die eine andere Komponente aufrufen kann und die dem Treiber mitteilt, welche Einstellungen er zurückgeben oder wie er bestimmte Einstellungen ändern soll. Der Treiberdienst könnte zum Beispiel eine IOCTL-Schnittstelle über eine Geräteschnittstelle bereitstellen.

In der Regel stellt der Treiber, dem der Status gehört, eine Geräteschnittstelle in einer angepassten Geräteschnittstellenklasse zur Verfügung. Wenn der Treiber bereit ist, dass andere Komponenten auf den Status zugreifen können, aktiviert er die Schnittstelle. Um benachrichtigt zu werden, wenn eine Geräteschnittstelle aktiviert ist, können sich Benutzer*innen für Geräteschnittstellen-Ankunftsbenachrichtigungen registrieren und Kernel-Komponenten können IoRegisterPlugPlayNotification verwenden. Damit diese Komponenten auf den Status zugreifen können, muss der Treiber, der die Schnittstelle aktiviert, einen Vertrag für seine angepasste Geräte-Schnittstellenklasse definieren. Dieser Vertrag ist in der Regel eine von zwei Arten:

• Ein E/A-Vertrag kann mit dieser Geräte-Schnittstellenklasse verknüpft werden, der einen Mechanismus für den Zugriff auf den Status bereitstellt. Andere Komponenten verwenden die aktivierte Geräteschnittstelle, um E/A-Anfragen zu senden, die dem Vertrag entsprechen.

• Eine Direct-Call-Schnittstelle, die über eine Abfrage-Schnittstelle zurückgegeben wird. Andere Treiber könnten IRP_MN_QUERY_INTERFACE senden, um Funktionszeiger von dem aufzurufenden Treiber zu erhalten.

Wenn der Treiber, dem der Status gehört, den direkten Zugriff auf den Status zulässt, könnten andere Treiber alternativ auf den Status zugreifen, indem sie die vom System bereitgestellten Funktionen für den programmgesteuerten Zugriff auf den Status der Geräteschnittstelle verwenden. Weitere Informationen finden Sie unter Geräteschnittstellen-Registrierungsstatus.

Diese Schnittstellen oder der Status (je nach verwendeter Freigabemethode) müssen ordnungsgemäß versioniert werden, damit der Treiber, dem der Status gehört, unabhängig von anderen Komponenten, die auf diesen Status zugreifen, gewartet werden kann. Die Anbieter von Treibern können sich nicht darauf verlassen, dass andere Komponenten zur gleichen Zeit wie der Treiber gewartet werden und auf der gleichen Version bleiben.

Da Geräte und Treiber, die Schnittstellen steuern, kommen und gehen, sollten Treiber und Anwendungen den Aufruf von IoGetDeviceInterfaces beim Start der Komponente vermeiden, um eine Liste der aktivierten Schnittstellen zu erhalten. Stattdessen ist es am besten, sich für Benachrichtigungen über das Eintreffen oder Entfernen von Geräteschnittstellen zu registrieren und dann die entsprechende Funktion aufzurufen, um die Liste der auf dem Computer vorhandenen aktivierten Schnittstellen zu erhalten.

Weitere Informationen über Geräteschnittstellen finden Sie unter:

• Verwenden von Geräteschnittstellen

• Registrieren für die Benachrichtigung über den Empfang der Geräteschnittstelle und das Entfernen von Geräten

• Registrieren für die Änderungsbenachrichtigungen über die Geräteschnittstelle

Kurzreferenz der Betriebssystemunterstützung für Status-Management-APIs

Die meisten Treiberpakete müssen eine Reihe von Betriebssystemversionen unterstützen. Unter Unterstützung mehrerer Betriebssystemversionen finden Sie weitere Informationen darüber, wie Sie dies in einem Treiberpaket erreichen. In den folgenden Tabellen finden Sie eine Kurzreferenz darüber, wann der Betriebssystem-Support für verschiedene Status-Management-APIs hinzugefügt wurde.

WDM-Treiber

KMDF-Treiber

UMDF-Treiber

Benutzermodus-Code