Richtlinien für das Schreiben von AddDevice-Routinen

Beachten Sie beim Schreiben einer AddDevice-Routine die folgenden Entwurfsrichtlinien:

• Wenn ein Filtertreiber feststellt, dass seine AddDevice-Routine für ein Gerät aufgerufen wurde, das er nicht warten muss, muss der Filtertreiber STATUS_SUCCESS zurückgeben, damit der Rest des Gerätestapels für das Gerät geladen werden kann. Der Filtertreiber erstellt kein Geräteobjekt und fügt es nicht an den Gerätestapel an. Der Filtertreiber gibt nur success zurück und ermöglicht das Hinzufügen der restlichen Treiber zum Stapel.

• Ein Treiber muss Speicher bereitstellen, in der Regel in der Geräteerweiterung eines Geräteobjekts, für alle kerneldefinierte Objekte und von der Exekutive verwendeten Spinsperren. Ein Treiber muss außerdem Speicher für Zeiger auf bestimmte Objekte bereitstellen, die vom E/A-Manager oder anderen Systemkomponenten abgerufen werden.

  Sie können sich entscheiden, zusätzlichen Systemspeicher für die Anforderungen des Treibers zuzuweisen, z. B. für langfristige E/A-Puffer oder eine Suchliste. Wenn ja, kann eine AddDevice-Routine die folgenden Routinen aufrufen:

  ExAllocatePoolWithTag für ausgelagerten oder nicht ausgelagerten Systemspeicherspeicher

  ExInitializePagedLookasideList oder ExInitializeNPagedLookasideList zum Initialisieren einer ausgelagerten oder nicht ausgelagerten Lookaside-Liste

• Wenn der Treiber über einen dedizierten Gerätethread verfügt oder auf kerneldefinierte Dispatcherobjekte wartet, kann die AddDevice-RoutineKernelverteilerobjekte initialisieren.

• Wenn der Treiber Spinsperren der Führungskraft verwendet oder den Speicher für eine Unterbrechungs-Spinsperre bereitstellt, kann die AddDevice-Routine diese Spinsperren initialisieren. Weitere Informationen finden Sie unter Spin-Sperren .

• Erhöhen Sie die Sicherheit beim Öffnen von Dateien beim Aufrufen von IoCreateDevice.

  Geben Sie das FILE_DEVICE_SECURE_OPEN-Merkmal für den Aufruf von IoCreateDevice an. Diese Eigenschaft wird unter Windows NT 4.0 SP5 und höher unterstützt. Er weist den E/A-Manager an, sicherheitsrelevante Überprüfungen für das Geräteobjekt für alle offenen Anforderungen durchzuführen. Anbieter sollten dieses Merkmal bei Aufrufen von IoCreateDevice angeben, wenn das FILE_DEVICE_SECURE_OPEN Merkmal nicht im Klasseninstallationsprogramm des Geräts inF oder in der INF des Geräts festgelegt ist und die Treiber keine eigenen Sicherheitsüberprüfungen bei Geöffneten durchführen. (Weitere Informationen finden Sie unter Steuern des Gerätenamespacezugriffs.)

  Wenn ein Treiber beim Aufrufen von IoCreateDevice das FILE_DEVICE_SECURE_OPEN Merkmal festlegt, wendet der E/A-Manager den Sicherheitsdeskriptor des Geräteobjekts auf alle relativen geöffneten oder nachgestellten Dateinamen an. Wenn beispielsweise FILE_DEVICE_SECURE_OPEN für \Device\foo festgelegt ist und \Device\foo nur vom Administrator geöffnet werden kann, kann \Device\foo\abc auch vom Administrator geöffnet werden. Der E/A-Manager verhindert jedoch, dass ein normaler Benutzer \Device\foo und \Device\foo\abc öffnet.

  Wenn ein Treiber für ein Gerät diese Eigenschaft festlegt, gibt der PnP-Manager sie an alle Geräteobjekte für das Gerät weiter.

Wichtig

Die in diesem Thema beschriebenen ExAllocatePool-DDIs sind in Windows 10 Version 2004 veraltet und wurden durch ExAllocatePool2 und ExAllocatePool3 ersetzt. Weitere Informationen finden Sie unter Aktualisieren veralteter ExAllocatePool-Aufrufe von ExAllocatePool2 und ExAllocatePool3.