DispatchPnP-Routinen

Die DispatchPnP-Routine eines Treibers unterstützt Plug and Play durch Behandeln von IRPs für den IRP_MJ_PNP I/O-Funktionscode. Der Funktion IRP_MJ_PNP sind mehrere kleinere I/O-Funktionscodes zugeordnet (siehe Plug and Play Minor IRPs), von denen einige zwingend von allen Treibern behandelt werden müssen, während andere optional behandelt werden können. Der PnP-Manager verwendet diese Minor-Funktionscodes, um Treiber zum Starten, Stoppen und Entfernen von Geräten zu veranlassen und Treiber nach Informationen zu ihren Geräten abzufragen.

Alle Treiber für ein Gerät müssen die Möglichkeit haben, PnP-IRPs für das Gerät zu bearbeiten, außer in einigen Fällen, in denen ein Funktions- oder Filtertreiber berechtigt ist, das IRP scheitern zu lassen.

Jede DispatchPnP-Routine des Treibers muss die folgenden Regeln einhalten:

• Ein Funktions- oder Filtertreiber muss PnP-IRPs an den nächsten Treiber im Gerätestapel übergeben, es sei denn, der Funktions- oder Filtertreiber behandelt das IRP und stößt auf einen Fehler (z. B. aufgrund unzureichender Ressourcen).

  Alle Treiber für ein Gerät müssen die Möglichkeit haben, PnP-IRPs für das Gerät zu bearbeiten, es sei denn, einer der Treiber stößt auf einen Fehler. Der PnP-Manager sendet IRPs an den obersten Treiber in einem Gerätestapel. Funktions- und Filtertreiber übergeben das IRP an den nächsten Treiber, und der übergeordnete Bustreiber schließt das IRP ab. Weitere Informationen finden Sie unter Übergeben von PnP-IRPs nach unten im Gerätestapel .

  Ein Treiber kann ein IRP fehlschlagen lassen, wenn er versucht, das IRP zu bearbeiten, und ein Fehler auftritt (z. B. unzureichende Ressourcen). Wenn ein Treiber einen IRP mit einem Code empfängt, den er nicht behandelt, darf der Treiber den IRP nicht zurückweisen. Ein solches IRP muss an den nächsten Treiber übergeben werden, ohne den IRP-Status zu ändern.

• Ein Treiber muss bestimmte PnP-IRPs verarbeiten und kann optional andere verarbeiten.

  Jeder PnP-Treiber ist erforderlich, um bestimmte IRPs zu verarbeiten, z. B. IRP_MN_REMOVE_DEVICE, und kann optional andere verarbeiten. Unter Plug and Play Minor IRPs finden Sie Informationen dazu, welche IRPs für jede Art von Treiber erforderlich und optional sind (Funktionstreiber, Filtertreiber und Bustreiber).

  Ein Treiber kann einen erforderlichen PnP-IRP mit einem entsprechenden Fehlerstatus ablehnen, darf jedoch für einen solchen IRP nicht STATUS_NOT_SUPPORTED zurückgeben.

• Wenn ein Treiber ein PnP-IRP erfolgreich verarbeitet, legt der Treiber den IRP-Status auf Erfolg fest. Es hängt nicht von einem anderen Treiber im Stapel ab, um den Status festzulegen.

  Ein Treiber legt "Irp-IoStatus.Status>" auf STATUS_SUCCESS fest, um den PnP-Manager darüber zu informieren, dass der Treiber das IRP erfolgreich verarbeitet hat. Bei einigen IRPs kann sich ein Nicht-Bustreiber möglicherweise auf seinen übergeordneten Bustreiber verlassen, um den Status auf Erfolg festzulegen. Dies ist jedoch eine riskante Praxis. Um Konsistenz und Stabilität zu gewährleisten, muss ein Treiber den IRP-Status auf Erfolg für jede erfolgreich verarbeitete PnP-IRP festlegen.

• Wenn ein Treiber ein IRP fehlschlägt, schließt der Treiber das IRP mit einem Fehlerstatus ab und übergibt das IRP nicht an den nächsten Treiber.

  Wenn ein IRP wie IRP_MN_QUERY_STOP_DEVICE fehlschlägt, legt ein Treiber "Irp-IoStatus.Status>" auf STATUS_UNSUCCESSFUL fest. Weitere Fehlerstatuswerte für andere IRPs sind STATUS_INSUFFICIENT_RESOURCES und STATUS_INVALID_DEVICE_STATE.

  Treiber setzen für IRPs, die sie bearbeiten, kein STATUS_NOT_SUPPORTED fest. Dies ist der vom PnP-Manager festgelegte Anfangsstatus. Wenn ein IRP mit diesem Status abgeschlossen ist, bedeutet dies, dass keine Treiber im Stapel das IRP verarbeitet haben. alle Treiber haben das IRP an den nächsten Treiber übergeben.

• Ein Treiber muss ein PnP-IRP in seiner Verteilerroutine (auf dem IRP-Weg nach unten im Gerätestapel) in einer IoCompletion-Routine (auf dem IRP-Weg zurück zum Gerätestapel) oder beides verarbeiten, wie auf der Referenzseite für das IRP angegeben.

  Einige PnP-IRPs, z. B. IRP_MN_REMOVE_DEVICE, müssen zuerst vom Treiber am oberen Rand des Gerätestapels und dann von jedem nächsten niedrigeren Treiber behandelt werden. Andere, z. B. IRP_MN_START_DEVICE, müssen zuerst vom übergeordneten Busfahrer behandelt werden. Andere, z. B. IRP_MN_QUERY_CAPABILITIES, können sowohl auf dem Weg nach unten im Gerätestapel als auch auf dem Weg nach oben behandelt werden. Informationen zu den Regeln, die für die einzelnen PnP-IRP gelten, finden Sie unter Plug and Play Minor IRPs . Siehe "Postponing PnP IRP Processing Until Lower Drivers Finish" für Informationen über das Bearbeiten von PnP-IRPs, die zuerst vom übergeordneten Bustreiber verarbeitet werden müssen.

• Ein Treiber muss Informationen zu einem IRP hinzufügen, wenn es im Gerätestapel nach unten geht, und Informationen ändern oder entfernen, wenn es im Gerätestapel wieder nach oben geht.

  Wenn Informationen als Reaktion auf eine PnP-Abfrage an die IRP zurückgegeben werden, muss ein Treiber dieser Konvention folgen, um eine geordnete Informationsübermittlung durch die gestapelten Treiber für ein Gerät zu ermöglichen.

• Sofern nicht explizit dokumentiert, darf ein Treiber nicht von PnP-IRPs abhängig sein, die in einer bestimmten Reihenfolge gesendet werden.

• Wenn ein Treiber einen PnP-IRP sendet, muss er den IRP an den oberen Treiber im Gerätestapel senden.

  Die meisten PnP-IRPs werden vom PnP-Manager gesendet, aber einige können von Treibern gesendet werden (z. B. IRP_MN_QUERY_INTERFACE). Ein Treiber muss einen PnP-IRP an den Treiber am obersten Ende des Gerätestapels senden. Rufen Sie IoGetAttachedDeviceReference auf, um einen Zeiger auf das Geräteobjekt für den Treiber am oberen Rand des Gerätestapels abzurufen.