Treiberpaketisolation
Die Treiberpaketisolation ist eine Voraussetzung für Windows-Treiber , die Treiberpakete resilienter gegenüber externen Änderungen, einfacher zu aktualisieren und einfacher zu installieren macht.
Hinweis
Die Treiberpaketisolation ist zwar für Windows-Treiber erforderlich, aber Windows-Desktoptreiber profitieren weiterhin von dieser Isolation durch verbesserte Resilienz und Servicefähigkeit.
Die folgende Tabelle enthält einige Beispielmethoden für Legacytreiberpakete, die für Windows-Treiber in der linken Spalte nicht mehr zulässig sind, sowie das erforderliche Verhalten für Windows-Treiber in der rechten Spalte.
| Nicht isolierter Treiber | Isolierter Treiber |
|---|---|
| INF kopiert Dateien nach %windir%\System32 oder %windir%\System32\drivers | Treiberdateien werden aus dem Treiberspeicher ausgeführt. |
| Interagiert mit Gerätestapeln/Treibern unter Verwendung hartcodierter Pfade | Interagiert mit Gerätestapeln/Treibern mithilfe von vom System bereitgestellten Funktionen oder Geräteschnittstellen |
| Hartcodieren des Pfads zu globalen Registrierungsspeicherorten | Verwendet HKR und vom System bereitgestellte Funktionen für den relativen Speicherort des Registrierungs- und Dateistatus. |
| Laufzeitdatei schreibt an einen beliebigen Speicherort | Dateien werden relativ zu speicherorten geschrieben, die vom Betriebssystem bereitgestellt werden. |
Hilfe bei der Ermittlung, ob Ihr Treiberpaket die Isolationsanforderungen für Treiberpakete erfüllt, finden Sie unter Überprüfen von Windows-Treibern. Beispiele für das Aktualisieren eines INF zur Erfüllung der Anforderungen an die Treiberpaketisolation finden Sie unter Portieren eines INF zur Treiberpaketisolation.
Ausführen aus dem Treiberspeicher
Alle isolierten Treiberpakete belassen ihre Treiberpaketdateien im Treiberspeicher. Dies bedeutet, dass sie DIRID 13 in ihrem INF angeben, um den Speicherort für Treiberpaketdateien bei der Installation anzugeben. Weitere Informationen zur Verwendung in einem Treiberpaket finden Sie unter Ausführen aus dem Treiberspeicher.
Lese- und Schreibzustand
Hinweis
Wenn Ihre Komponente Geräte- oder Geräteschnittstelleneigenschaften zum Speichern des Zustands verwendet, verwenden Sie weiterhin diese Methode und die entsprechenden Betriebssystem-APIs, um den Zustand zu speichern und darauf zuzugreifen. Die folgende Anleitung für den Registrierungs- und Dateistatus bezieht sich auf einen anderen Zustand, der von einer Komponente gespeichert werden muss.
Der Zugriff auf verschiedene Registrierungs- und Dateistatus sollte durch Aufrufen von Funktionen erfolgen, die einen Aufrufer mit dem Speicherort des Zustands bereitstellen, und dann wird der Zustand in Bezug auf diesen Speicherort gelesen/geschrieben. Verwenden Sie keine hartcodierten absoluten Registrierungspfade und Dateipfade.
Dieser Abschnitt enthält die folgenden Unterabschnitte:
Registrierungsstatus
Dieser Abschnitt enthält die folgenden Unterabschnitte:
PnP-Geräteregistrierungsstatus
Isolierte Treiberpakete und Benutzermoduskomponenten verwenden in der Regel einen von zwei Speicherorten, um den Gerätestatus 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 ein einzelnes Gerät instance mit der Hardware interagiert. Beispielsweise, um ein Hardwarefeature zu aktivieren oder die Hardware in einen bestimmten Modus zu versetzen. Der Softwareschlüssel ist in der Regel für Einstellungen vorgesehen, die sich darauf beziehen, wie ein einzelnes Gerät instance mit dem System und anderen Software interagiert. Beispielsweise, um den Speicherort einer Datendatei zu konfigurieren, um mit einem Framework zu arbeiten oder auf App-Einstellungen für ein Gerät zuzugreifen. Verwenden Sie eine der folgenden Optionen, um ein Handle für diese Registrierungsspeicherorte abzurufen:
IoOpenDeviceRegistryKey (WDM)
CM_Open_DevNode_Key (Benutzermoduscode)
INF AddReg-Direktive mit HKR-Reg-Root-Einträgen in einem Add-Registry-Abschnitt , auf den von einem INF DDInstall-Abschnitt oder abschnitt DDInstall.HW verwiesen wird, wie unten gezeigt:
[ExampleDDInstall.HW]
AddReg = Example_DDInstall.AddReg
[Example_DDInstall.AddReg]
HKR,,ExampleValue,,%13%\ExampleFile.dll
Registrierungsstatus der Geräteschnittstelle
Verwenden Sie eine der folgenden Optionen, um den Registrierungsstatus der Geräteschnittstelle zu lesen und zu schreiben:
CM_Open_Device_Interface_Key (Benutzermoduscode)
INF AddReg-Direktive mit HKR-Reg-Root-Einträgen in einem add-registry-abschnitt , auf den aus einem abschnitt add-interface-section verwiesen wird
Dienstregistrierungsstatus
Der Dienststatus sollte in eine von drei Kategorien eingeteilt werden.
Unveränderlicher Registrierungsstatus des Diensts
Unveränderlicher Dienststatus ist der Zustand, der vom Treiberpaket bereitgestellt wird, das den Dienst installiert. Diese Registrierungswerte, die vom INF für Treiber- und Win32-Dienste festgelegt werden, müssen unter dem Unterschlüssel "Parameters" des Diensts gespeichert werden, indem sie eine HKR-Zeile in einem AddReg-Abschnitt angeben und dann auf diesen Abschnitt im Abschnitt "Dienstinstallation" im INF verweisen. 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
Verwenden Sie eine der folgenden Funktionen, um über den Dienst zur Laufzeit auf den Speicherort dieses Zustands zuzugreifen:
IoOpenDriverRegistryKey (WDM) mit einer DRIVER_REGKEY_TYPE driverRegKeyParameters
GetServiceRegistryStateKey (Win32 Services) mit einer SERVICE_REGISTRY_STATE_TYPE von ServiceRegistryStateParameters
Diese Registrierungswerte, die vom INF im Unterschlüssel "Parameters" für den Dienst bereitgestellt werden, sollten nur zur Laufzeit gelesen und nicht geändert werden. Sie sollten als schreibgeschützter Schreibschutz behandelt werden.
Wenn es sich bei den vom INF bereitgestellten Registrierungswerten um Standardeinstellungen handelt, die zur Laufzeit überschrieben werden können, sollten die Außerkraftsetzungswerte in den Registrierungsstatus interner Dienst oder in den Registrierungsstatus des freigegebenen Diensts für den Dienst geschrieben werden. Beim Abrufen der Einstellungen kann die Einstellung zuerst im veränderlichen Zustand gesucht werden. Wenn sie dort nicht vorhanden ist, kann die Einstellung im unveränderlichen Zustand gesucht werden. RtlQueryRegistryValueWithFallback kann verwendet werden, um Abfrageeinstellungen wie diese mit einer Außerkraftsetzung und einem Standardwert zu unterstützen.
Status der internen Dienstregistrierung
Der interne Dienststatus ist ein Zustand, der zur Laufzeit geschrieben und nur vom Dienst selbst verwaltet wird und nur für diesen Dienst zugänglich ist. Um auf den Speicherort für den internen Dienststatus zuzugreifen, verwenden Sie eine der folgenden Funktionen aus dem Dienst:
IoOpenDriverRegistryKey (WDM) mit dem DRIVER_REGKEY_TYPE DriverRegKeyPersistentState
GetServiceRegistryStateKey (Win32 Services) mit einer SERVICE_REGISTRY_STATE_TYPE von ServiceRegistryStatePersistent
Wenn der Dienst zulassen möchte, dass andere Komponenten diese Einstellungen ändern können, muss der Dienst eine Schnittstelle verfügbar machen, die eine andere Komponente aufrufen kann, die dem Dienst mitteilt, wie diese Einstellungen geändert werden sollen. Beispielsweise könnte ein Win32-Dienst eine COM- oder RPC-Schnittstelle und ein Treiberdienst eine IOCTL-Schnittstelle über eine Geräteschnittstelle verfügbar machen.
Registrierungsstatus für gemeinsam genutzte Dienste
Der Zustand des freigegebenen Diensts ist ein Zustand, der zur Laufzeit geschrieben wird und für andere Benutzermoduskomponenten freigegeben werden kann, wenn diese ausreichend privilegiert sind. Verwenden Sie eine der folgenden Funktionen, um auf den Speicherort für diesen Zustand des gemeinsam genutzten Diensts zuzugreifen:
IoOpenDriverRegistryKey (WDM) mit einer DRIVER_REGKEY_TYPE driverRegKeySharedPersistentState
GetSharedServiceRegistryStateKey (Win32 Services) mit einer SERVICE_SHARED_REGISTRY_STATE_TYPE von ServiceSharedRegistryPersistentState
Dateistatus
Dieser Abschnitt enthält die folgenden Unterabschnitte:
Gerätedateistatus
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 betriebssystem-API bereitgestellt wird. Konfigurationsdateien, die für dieses Gerät spezifisch sind, sind ein Beispiel dafür, welche Dateitypen hier gespeichert werden sollen. Verwenden Sie eine der folgenden Funktionen aus dem Dienst, um auf den Speicherort dieses Zustands zuzugreifen:
IoGetDeviceDirectory (WDM) mit dem DirectoryType-Parameter , der auf DeviceDirectoryData festgelegt ist
Dienstdateistatus
Der Status der Dienstdatei kann in eine von drei Kategorien klassifiziert werden.
Unveränderlicher Dienstdateistatus
Unveränderlicher Dienstdateistatus sind Dateien, die Teil des Treiberpakets sind. Weitere Informationen zum Zugriff auf diese Dateien finden Sie unter Ausführen aus dem Treiberspeicher.
Interner Dienstdateistatus
Interner Dienstdateistatus ist der Zustand, der zur Laufzeit geschrieben und nur vom Dienst selbst verwaltet wird und nur für diesen Dienst zugänglich ist. Um auf den Speicherort für den internen Dienststatus zuzugreifen, verwenden Sie eine der folgenden Funktionen aus dem Dienst:
IoGetDriverDirectory (WDM, KMDF) mit dem DirectoryType-Parameter , der auf DriverDirectoryData festgelegt ist
GetServiceDirectory (Win32 Services) mit dem eDirectoryType-Parameter, der auf ServiceDirectoryPersistentState festgelegt ist
Wenn der Dienst zulassen möchte, dass andere Komponenten diese Einstellungen ändern können, muss der Dienst eine Schnittstelle verfügbar machen, die eine andere Komponente aufrufen kann, die dem Dienst mitteilt, wie diese Einstellungen geändert werden sollen. Beispielsweise könnte ein Win32-Dienst eine COM- oder RPC-Schnittstelle und ein Treiberdienst eine IOCTL-Schnittstelle über eine Geräteschnittstelle verfügbar machen.
Dateistatus der freigegebenen Dienste
Der Dateistatus der freigegebenen Dienste ist der Zustand, der zur Laufzeit geschrieben wird und für andere Benutzermoduskomponenten freigegeben werden kann, wenn diese ausreichend privilegiert sind. Verwenden Sie eine der folgenden Funktionen, um auf den Speicherort für diesen Zustand des gemeinsam genutzten Diensts zuzugreifen:
IoGetDriverDirectory (WDM, KMDF) mit dem DirectoryType-Parameter , der auf DriverDirectorySharedData festgelegt ist
GetSharedServiceDirectory (Win32 Services) mit dem DirectoryType-Parameter, der auf ServiceSharedDirectoryPersistentState festgelegt ist
DriverData und ProgramData
Dateien, die für andere Komponenten freigegeben werden können, aber nicht in die Statuskategorie für freigegebene Dienstdateien passen, können entweder DriverData in oder ProgramData an Speicherorte geschrieben werden.
Diese Speicherorte bieten Komponenten einen Speicherort zum Schreiben eines temporären Zustands oder Zustands, der von anderen Komponenten genutzt und möglicherweise aus einem System gesammelt und kopiert werden soll, um von einem anderen System verarbeitet zu werden. Beispielsweise passen benutzerdefinierte Protokolldateien oder Absturzabbilder zu dieser Beschreibung.
Vermeiden Sie das Schreiben von Dateien im Stammverzeichnis des DriverData Verzeichnisses oder ProgramData des Verzeichnisses. Erstellen Sie stattdessen ein Unterverzeichnis mit dem Namen Ihres Unternehmens, und schreiben Sie dann Dateien und weitere Unterverzeichnisse innerhalb dieses Verzeichnisses.
Für den Unternehmensnamen Contoso könnte beispielsweise ein Kernelmodustreiber ein benutzerdefiniertes Protokoll \DriverData\Contoso\Logs schreiben und eine Benutzermodusanwendung die Protokolldateien aus %DriverData%\Contoso\Logssammeln oder analysieren.
DriverData
Das DriverData Verzeichnis ist in Windows 10 Version 1803 und höher verfügbar und kann für Administratoren und UMDF-Treiber zugänglich sein.
Kernelmodustreiber greifen mithilfe einer vom System bereitgestellten symbolischen Verknüpfung namens \DriverDataauf das DriverData Verzeichnis zu.
Benutzermodusprogramme greifen mithilfe der DriverData Umgebungsvariable %DriverData%auf das Verzeichnis zu.
ProgramData
Die %ProgramData% Benutzermodus-Umgebungsvariable ist für Benutzermoduskomponenten verfügbar, die beim Speichern von Daten verwendet werden können.
Temporäre Dateien
Temporäre Dateien werden in der Regel in zwischengeschalteten Vorgängen verwendet. Diese können in einen Unterpfad unter den Umgebungsvariablen %TEMP% oder %TMP% geschrieben werden. Da auf diese Speicherorte über Umgebungsvariablen zugegriffen wird, ist diese Möglichkeit auf Komponenten im Benutzermodus beschränkt. Es gibt keine Garantien für die Lebensdauer oder Persistenz dieser temporären Dateien, nachdem die Handles für sie geschlossen wurden. Das Betriebssystem oder der Benutzer kann sie jederzeit entfernen, und sie können nicht während eines Neustarts beibehalten werden.
Vermeiden Sie das Schreiben von Dateien im Stammverzeichnis des %TEMP% Verzeichnisses oder %TMP% des Verzeichnisses. Erstellen Sie stattdessen ein Unterverzeichnis mit dem Namen Ihres Unternehmens, und schreiben Sie dann Dateien und weitere Unterverzeichnisse innerhalb dieses Verzeichnisses.
Eigenschaftsstatus
Sowohl Geräte als auch Geräteschnittstellen unterstützen das Speichern des Zustands über das PnP-Eigenschaftenmodell. Das Eigenschaftenmodell ermöglicht das Speichern strukturierter Eigenschaftendaten auf einem Gerät oder einer Geräteschnittstelle. Dies ist für kleinere Daten gedacht, die vernünftigerweise in die vom Eigenschaftenmodell unterstützten Eigenschaftstypen passen.
Für den Zugriff auf Geräteeigenschaften können diese APIs verwendet werden:
WDM-Treiber
WDF-Treiber
Benutzermoduscode
Für den Zugriff auf Geräteschnittstelleneigenschaften können diese APIs verwendet werden:
WDM-Treiber
WDF-Treiber
Benutzermoduscode
Verwenden von Geräteschnittstellen
Wenn ein Treiber anderen Komponenten erlauben möchte, den internen Zustand des Treibers zu lesen oder zu ändern, sollte der Treiber eine Schnittstelle verfügbar machen, die eine andere Komponente aufrufen kann, die dem Treiber mitteilt, welche Einstellungen zurückgegeben oder wie bestimmte Einstellungen geändert werden sollen. Der Treiberdienst könnte beispielsweise eine IOCTL-Schnittstelle über eine Geräteschnittstelle verfügbar machen.
In der Regel macht der Treiber, der den Zustand besitzt, eine Geräteschnittstelle in einer benutzerdefinierten Geräteschnittstellenklasse verfügbar. Wenn der Treiber bereit ist, dass andere Komponenten zugriff auf den Zustand haben, aktiviert er die -Schnittstelle. Um benachrichtigt zu werden, wenn eine Geräteschnittstelle aktiviert ist, können Sich Benutzermoduskomponenten für Benachrichtigungen zum Eintreffen der Geräteschnittstelle registrieren, und Kernelmoduskomponenten können IoRegisterPlugPlayNotification verwenden. Damit diese Komponenten auf den Zustand zugreifen können, muss der Treiber, der die Schnittstelle aktiviert, einen Vertrag für seine benutzerdefinierte Geräteschnittstellenklasse definieren. Dieser Vertrag besteht in der Regel aus zwei Arten:
Dieser Geräteschnittstellenklasse kann ein E/A-Vertrag zugeordnet werden, der einen Mechanismus für den Zugriff auf den Zustand bereitstellt. Andere Komponenten verwenden die aktivierte Geräteschnittstelle, um E/A-Anforderungen zu senden, die dem Vertrag entsprechen.
Eine Direktaufrufschnittstelle , die über eine Abfrageschnittstelle zurückgegeben wird. Andere Treiber könnten IRP_MN_QUERY_INTERFACE senden, um Funktionszeiger vom Treiber abzurufen, um ihn aufzurufen.
Wenn der Treiber, der den Zustand besitzt, direkten Zugriff auf den Zustand zulässt, können andere Treiber auch auf den Zustand zugreifen, indem sie vom System bereitgestellte Funktionen für den programmgesteuerten Zugriff auf den Geräteschnittstellenzustand verwenden. Weitere Informationen finden Sie unter Registrierungsstatus der Geräteschnittstelle .
Diese Schnittstellen oder der Zustand (abhängig von der verwendeten Freigabemethode) müssen ordnungsgemäß versioniert werden, damit der Treiber, der den Zustand besitzt, unabhängig von anderen Komponenten gewartet werden kann, die auf diesen Zustand zugreifen. Treiberhersteller können sich nicht darauf verlassen, dass andere Komponenten gleichzeitig mit dem Treiber gewartet werden und dieselbe Version beibehalten werden.
Da Geräte und Treiber, die Schnittstellen steuern, kommen und gehen, sollten Treiber und Anwendungen den Aufruf von IoGetDeviceInterfaces beim Komponentenstart vermeiden, um eine Liste der aktivierten Schnittstellen zu erhalten. Stattdessen besteht die bewährte Methode darin, sich für Benachrichtigungen über das Eintreffen oder Entfernen der Geräteschnittstelle zu registrieren und dann die entsprechende Funktion aufzurufen, um die Liste der vorhandenen aktivierten Schnittstellen auf dem Computer abzurufen.
Weitere Informationen zu Geräteschnittstellen finden Sie unter:
Registrieren für die Benachrichtigung über die Ankunft der Geräteschnittstelle und Geräteentfernung
Registrieren für die Änderungsbenachrichtigung der Geräteschnittstelle
Kurzübersicht zur Betriebssystemunterstützung für Zustandsverwaltungs-APIs
Die meisten Treiberpakete müssen eine Reihe von Betriebssystemversionen unterstützen. Weitere Informationen dazu, wie Sie dies in einem Treiberpaket erreichen, finden Sie unter Unterstützen mehrerer Betriebssystemversionen . Die folgenden Tabellen enthalten eine kurze Übersicht darüber, wann Betriebssystemunterstützung für verschiedene Zustandsverwaltungs-APIs hinzugefügt wurde.
WDM-Treiber
| Betriebssystem | Unterstützung hinzugefügt |
|---|---|
| Windows 2000 | IoOpenDeviceRegistryKey IoOpenDeviceInterfaceRegistryKey |
| Windows Vista | IoGetDevicePropertyData IoSetDevicePropertyData |
| Windows 8 | IoGetDeviceInterfacePropertyData IoSetDeviceInterfacePropertyData |
| Windows 8.1 | IoQueryFullDriverPath |
| Windows 10 1803 | IoOpenDriverRegistryKey für RegKeyType of DriverRegKeyParameters and DriverRegKeyPersistentState IoGetDeviceDirectory IoGetDriverDirectory for DirectoryType of DriverDirectoryImage und DriverDirectoryData |
| Windows 10 1809 | RtlQueryRegistryValueWithFallback |
| Windows 11 21H2 | IoOpenDriverRegistryKey for RegKeyType of DriverRegKeySharedPersistentState IoGetDriverDirectory for DirectoryType of DriverDirectorySharedData |
KMDF-Treiber
UMDF-Treiber
Benutzermoduscode
| Betriebssystem | Unterstützung hinzugefügt |
|---|---|
| Windows 2000 | CM_Open_DevNode_Key |
| Windows Vista | CM_Open_Device_Interface_Key CM_Get_DevNode_Property CM_Set_DevNode_Property CM_Get_Device_Interface_Property CM_Set_Device_Interface_Property |
| Windows 10 2004 | GetServiceRegistryStateKey GetServiceDirectory |
| Windows 11 21H2 | GetSharedServiceRegistryStateKey GetSharedServiceDirectory |
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für