Verwenden von Gerätepooling in UMDF-Treibern

User-Mode Driver Framework (UMDF) Version 1.11 und 2.0

Wenn Ihr User-Mode Driver Framework (UMDF)-Treiber mit Version 1.11 oder 2.0 erstellt wurde und auf Windows 8 oder höher ausgeführt wird, erstellt das Framework eine einzelne instance von Wudfhost, die mehrere Gerätestapel hosten kann. Diese Technik wird als Gerätepooling bezeichnet. Der Standard Vorteil von Gerätepools ist die Reduzierung des Arbeitsspeicherverbrauchs in einer Umgebung mit mehreren UMDF-Geräten.

Wenn ein Poolgerät ausfällt, beendet das Framework die instance von Wudfhost und versucht, alle Geräte neu zu starten, die sich zuvor im Pool befanden. Wenn das Gerät während des Pools erneut ausfällt, erstellt das Framework einen separaten Wudfhost-Prozess für das Gerät und versucht, das Gerät erneut zu starten.

Wenn das Gerät im separaten Hostprozess fehlschlägt, versucht das Framework, es bis zu fünf Mal neu zu starten. Das Framework setzt die Gerätefehleranzahl auf eine zurück, wenn seit dem letzten Fehler dreißig Minuten vergangen sind.

Wenn das System neu gestartet wird, werden geräte mit Ausnahme von Geräten, die bei der Ausführung in einem separaten Prozess fehlgeschlagen sind, vom Framework neu gruppiert.

Um das Gerätepooling für ein bestimmtes Gerät zu deaktivieren, verwenden Sie die UmdfHostProcessSharing-Anweisung im WDF-spezifischen DDInstall-Abschnitt des INF. Informationen zu UmdfHostProcessSharing finden Sie unter Angeben von WDF-Anweisungen in INF-Dateien.

Wenn Ihr Treiber direkte E/A verwendet, müssen Sie UmdfHostProcessSharing auf ProcessSharingDisabled festlegen. Andernfalls kann der Treiber nicht gestartet werden. Wenn WdfDeviceIoBufferedOrDirect ausgewählt ist und das Gerät pooling ist, ändert das Framework die Pufferzugriffsmethode in gepufferte E/A-Vorgänge. Wenn WdfDeviceIoBufferedOrDirect ausgewählt ist und das Gerät nicht im Pool zusammengefasst ist, ändert das Framework die Pufferzugriffsmethode, um eine direkte E/A zu leiten.

Um eine Pufferzugriffsmethode auszuwählen, muss Ihr Treiber die IWDFDeviceInitialize2::SetIoTypePreference-Methode über seine IDriverEntry::OnDeviceAdd-Rückruffunktion aufrufen. Informationen zu Zugriffsmethoden finden Sie unter Zugreifen auf Datenpuffer in UMDF-Based Treibern.

UMDF-Versionen 1.9 und früher

Wenn Ihr Treiber mit UMDF-Version 1.9 oder früher erstellt wurde, erstellt das Framework eine separate instance des Hostprozesses (Wudfhost) für jeden Gerätestapel.

Wenn das Gerät nicht gestartet werden kann, versucht das Framework, es bis zu fünf Mal neu zu starten. Das Framework setzt die Gerätefehleranzahl auf eine zurück, wenn seit dem letzten Fehler dreißig Minuten vergangen sind.

Wenn mehrere Gerätestapel in einer Umgebung ohne Pool denselben UMDF-Treiber verwenden:

• Jeder Gerätestapel lädt in einem separaten WudfHost-Prozess.
• Das Framework ruft die Methoden IDriverEntry::OnInitialize und IDriverEntry::OnDeinitialize des Treibers einmal für jeden Gerätestapel auf.
• Das Framework ruft die IDriverEntry::OnDeviceAdd-Methode des Treibers einmal für jeden Gerätestapel auf. Jedem Geräteobjekt ist ein separates Treiberobjekt zugeordnet.

Wenn mehrere Gerätestapel in einer Poolumgebung denselben Benutzermodustreiber verwenden:

• Jeder Gerätestapel wird im gleichen WudfHost-Prozess geladen.
• Das Framework ruft die Methoden IDriverEntry::OnInitialize und IDriverEntry::OnDeinitialize des Treibers nur einmal auf.
• Das Framework ruft die IDriverEntry::OnDeviceAdd-Methode des Treibers einmal für jeden Gerätestapel auf. Jedes Geräteobjekt ist demselben Treiberobjekt zugeordnet.

Da nur ein Treiberobjekt in einer Poolkonfiguration vorhanden ist, darf der Treiber keinen gerätespezifischen Kontext in globalen Variablen oder in Objekten speichern, die für alle Geräte freigegeben werden, z. B. das Treiberrückrufobjekt. Stattdessen muss der Treiber den gerätespezifischen Kontext in einem Objekt speichern, das nicht für die Gerätestapel freigegeben wird, z. B. das Geräterückrufobjekt des Treibers.