Unterstützung Kernel-Mode Clients in UMDF-Treibern

In diesem Thema wird beschrieben, wie ein UMDF-Treiber (User-Mode Driver Framework) Clients im Kernelmodus ab UMDF Version 2 unterstützt.

Ein Kernelmodusclient ist ein Kernelmodustreiber, der E/A-Anforderungen an Ihren UMDF-Treiber sendet. Der Kernelmodustreiber befindet sich möglicherweise über dem UMDF-Treiber, im gleichen Gerätestapel oder in einem anderen Gerätestapel.

Der Kernelmodustreiber kann E/A-Anforderungen weiterleiten, die er von einer Benutzermodusanwendung empfangen hat, oder neue E/A-Anforderungen erstellen und an den Benutzermodustreiber senden.

Unterstützung von Kernelmodusclients in einem UMDF-Treiber

Um die Unterstützung eines UMDF-Treibers für Kernelmodusclients zu aktivieren, muss die INF-Datei des UMDF-Treibers eine UmdfKernelModeClientPolicy-Direktive in ihrem INF DDInstall enthalten. WDF-Abschnitt .

Das Framework stellt zwei Methoden bereit, die für Treiber nützlich sind, die Kernelmodusclients unterstützen. Ein Treiber kann die WdfRequestGetRequestorMode-Methode aufrufen, um zu bestimmen, ob eine E/A-Anforderung aus dem Kernelmodus oder dem Benutzermodus stammt. Wenn die E/A-Anforderung aus dem Benutzermodus stammt, kann der Treiber WdfRequestIsFromUserModeDriver aufrufen, um zu bestimmen, ob die Anforderung von einer Anwendung oder einem anderen Benutzermodustreiber stammt.

Einschränkungen für Kernelmodustreiber

Ein UMDF-Treiber kann E/A-Anforderungen von einem Kernelmodustreiber nur verarbeiten, wenn der Kernelmodustreiber die folgenden Anforderungen erfüllt:

• Der Kernelmodustreiber muss unter IRQL = PASSIVE_LEVEL ausgeführt werden, wenn er die E/A-Anforderung sendet.

• Sofern der Treiber die InF-Direktive UmdfFileObjectPolicy nicht auf AllowNullAndUnknownFileObjects festgelegt hat, muss jede E/A-Anforderung, die ein Kernelmodustreiber an einen Benutzermodustreiber sendet, über ein zugeordnetes Dateiobjekt verfügen. Das Framework muss zuvor benachrichtigt worden sein, dass der E/A-Manager das Dateiobjekt erstellt hat. (Eine solche Benachrichtigung bewirkt, dass das Framework die Rückruffunktion EvtDeviceFileCreate des Benutzermodustreibers aufruft, aber diese Rückruffunktion ist optional.)

• Die E/A-Anforderung kann keinen IRP_MJ_INTERNAL_DEVICE_CONTROL Funktionscode enthalten.

• Die Puffer der E/A-Anforderung dürfen keine Zeiger auf zusätzliche Informationen enthalten, da der Benutzermodustreiber die Zeiger nicht ableiten kann.

• Wenn die E/A-Anforderung einen E/A-Steuerungscode enthält, der die Pufferzugriffsmethode "Weder" angibt, muss der Kernelmodustreiber die E/A-Anforderung im Prozesskontext der Anwendung senden, die die E/A-Anforderung erstellt hat. Weitere Informationen zur Unterstützung der Methode "Neither" in einem UMDF-Treiber finden Sie unter Verwalten von Pufferzugriffsmethoden in UMDF-Treibern.

• Der UMDF-Treiber kann die Ausgabedaten einer E/A-Anforderung im Benutzermodus ändern. Daher muss der Kernelmodustreiber alle Ausgabedaten überprüfen, die er vom Benutzermodustreiber empfängt.

• Der Kernelmodusclient sollte in der Regel den Informationswert überprüfen, den ein UMDF-Treiber an WdfRequestCompleteWithInformation übergibt. Wenn der Client ein KMDF-Treiber ist, kann er WdfRequestGetCompletionParams aufrufen, um diese Informationen in einer IO_STATUS_BLOCK-Struktur abzurufen.

  In der Regel überprüft das Framework nicht den Informationswert, den ein UMDF-Treiber an WdfRequestCompleteWithInformation übergibt. (Dieser Parameter gibt normalerweise die Anzahl der übertragenen Bytes an.) Das Framework überprüft den Informationswert nur für Ausgabepuffer und nur für die gepufferte E/A-Datenzugriffsmethode . (Das Framework überprüft beispielsweise, ob die Anzahl der übertragenen Bytes die Ausgabepuffergröße eines Lesevorgangs nicht überschreitet, wenn die Zugriffsmethode gepufferte E/A-Vorgänge ist.)