Behandeln von WDM-IRPs außerhalb des Frameworks

[Gilt nur für KMDF]

Wenn der E/A-Manager ein E/A-Anforderungspaket (IRP) an einen frameworkbasierten Treiber übermittelt, fängt das Framework das IRP ab und führt dann eine der folgenden Aktionen aus:

• Verarbeitet das IRP. Das Framework verarbeitet beispielsweise IRPs, die IRP_MJ_PNP und IRP_MJ_POWER haupt-E/A-Funktionscodes enthalten. Während der Verarbeitung dieser IRPs kann das Framework mit dem Treiber kommunizieren, indem die Ereignisrückruffunktionen des Treibers aufgerufen werden.

• Erstellt ein Frameworkanforderungsobjekt für das IRP und übermittelt das Anforderungsobjekt an eine der E/A-Warteschlangen des Treibers, damit der Treiber es empfangen und verarbeiten kann, in der Regel in einem Anforderungshandler. Das Framework verarbeitet Lese-, Schreib- und Geräte-E/A-Steuerungsanforderungen auf diese Weise.

• Übergibt den IRP an den nächstniedrigen Treiber (wenn ihr Treiber ein Filtertreiber ist) oder schließt den IRP mit dem status Wert STATUS_INVALID_DEVICE_REQUEST ab (wenn ihr Treiber kein Filtertreiber ist), da der IRP einen E/A-Funktionscode enthält, den das Framework nicht unterstützt.

Manchmal muss ein Treiber einen E/A-Funktionscode verarbeiten, der vom Framework nicht unterstützt wird.

In seltenen Fällen muss ein Treiber möglicherweise eine IRP vorverarbeiten, bevor das Framework sie verarbeitet, oder der Treiber muss einen IRP nachverarbeiten, nachdem das Framework und Treiber niedrigerer Ebene die Verarbeitung abgeschlossen haben.

Im Rahmen der Vorverarbeitung muss ein Treiber möglicherweise ein IRP an eine bestimmte E/A-Warteschlange weiterleiten.

In den folgenden Themen werden diese Situationen beschrieben:

• Behandeln einer IRP, die vom Framework nicht unterstützt wird
• Vor- und Nachverarbeitung von IRPs
• Senden von IRPs an E/A-Warteschlangen