Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
Der PnP-Manager sendet diese Anforderung, um bestimmte Beziehungen zwischen Geräten zu bestimmen. Die folgenden Treibertypen behandeln diese Anforderung:
Busfahrer müssen BusRelations Anforderungen für ihren Adapter oder Controller (Bus FDO) verarbeiten. Filtertreiber behandeln möglicherweise BusRelations- Anforderungen.
Bustreiber müssen TargetDeviceRelation Anforderungen für ihre untergeordneten Geräte (untergeordnete PDOs) verarbeiten.
Funktions- und Filtertreiber behandeln möglicherweise RemovalRelations- und PowerRelations-anforderungen.
Bustreiber behandeln möglicherweise EjectionRelations Anforderungen für ihre untergeordneten Geräte (untergeordnete PDOs).
Wert
0x07
Hauptcode
Wenn gesendet
Der PnP-Manager sendet dieses IRP, um Informationen zu Geräten mit einer Beziehung zum angegebenen Gerät zu sammeln.
Der PnP-Manager fragt die BusRelations (untergeordnete Geräte) eines Geräts ab, wenn das Gerät aufgezählt wird und zu anderen Zeiten aktiv ist, z. B. wenn ein Treiber die IoInvalidateDeviceRelations Routine aufruft, um anzugeben, dass ein untergeordnetes Gerät eingetroffen oder abgebrochen wurde.
Der PnP-Manager fragt die RemovalRelations- eines Geräts ab, bevor die Treiber eines Geräts entfernt werden. Der PnP-Manager fragt RemovalRelations und EjectionRelations ab, bevor es ein Gerät auswirft.
Der PnP-Manager fragt die TargetDeviceRelation eines Geräts ab, wenn sich ein Treiber oder eine Benutzermodusanwendung für die PnP-Benachrichtigung einer EventCategoryTargetDeviceChange auf dem Gerät registriert. Der PnP-Manager fragt nach dem Gerät ab, das einem bestimmten Dateiobjekt zugeordnet ist. IRP_MN_QUERY_DEVICE_RELATIONS ist der einzige PnP-IRP mit einem gültigen Dateiobjektparameter. Ein Treiber kann einen Gerätestapel für TargetDeviceRelation-abfragen. Ein Treiber muss beim Senden der TargetDeviceRelation Abfrage kein Dateiobjekt angeben.
Der PnP-Manager fragt die PowerRelations- eines Geräts ab, wenn der Treiber für das Gerät IoInvalidateDeviceRelations aufruft, um anzugeben, dass sich die Gruppe der Geräte, mit denen dieses Gerät über eine implizite Energieverwaltungsbeziehung verfügt, geändert hat. PowerRelations- Anforderungen werden ab Windows 7 unterstützt.
Für BusRelations, RemovalRelations, EjectionRelationsund PowerRelations Anforderungen sendet der PnP-Manager IRP_MN_QUERY_DEVICE_RELATIONS bei IRQL = PASSIVE_LEVEL im Kontext eines Systemthreads.
Für TargetDeviceRelation- Anforderungen sendet der PnP-Manager dieses IRP bei IRQL = PASSIVE_LEVEL in einem beliebigen Threadkontext.
Eingabeparameter
Der Parameters.QueryDeviceRelations.Type Member der IO_STACK_LOCATION-Struktur gibt den Typ der abgefragten Beziehungen an. Mögliche Werte sind BusRelations, EjectionRelations, RemovalRelations, TargetDeviceRelationund PowerRelations.
Das FileObject Member der aktuellen IO_STACK_LOCATION-Struktur verweist nur auf ein gültiges Dateiobjekt, wenn Parameters.QueryDeviceRelations.TypeTargetDeviceRelationist.
Ausgabeparameter
Wird im E/A-Statusblock zurückgegeben.
E/A-Statusblock
Ein Treiber legt Irp->IoStatus.Status- auf STATUS_SUCCESS oder auf einen Fehlerstatus wie STATUS_INSUFFICIENT_RESOURCES fest.
Bei Erfolg legt ein Treiber Irp->IoStatus.Information auf einen PDEVICE_RELATIONS Zeiger fest, der auf die angeforderten Beziehungsinformationen verweist. Die DEVICE_RELATIONS-Struktur ist wie folgt definiert:
typedef struct _DEVICE_RELATIONS {
ULONG Count;
PDEVICE_OBJECT Objects[1]; // variable length
} DEVICE_RELATIONS, *PDEVICE_RELATIONS;
Vorgang
Wenn ein Treiber als Reaktion auf diese IRP_MN_QUERY_DEVICE_RELATIONSBeziehungen zurückgibt, weist der Treiber eine DEVICE_RELATIONS Struktur aus dem ausgelagerten Speicher zu, die eine Anzahl und die entsprechende Anzahl von Geräteobjektzeigern enthält. Der PnP-Manager gibt die Struktur frei, wenn sie nicht mehr benötigt wird. Wenn ein Treiber eine DEVICE_RELATIONS Struktur ersetzt, die ein anderer Treiber zugewiesen hat, muss der Treiber die vorherige Struktur freigeben.
Ein Treiber muss auf die PDO jedes Geräts verweisen, das in diesem IRP gemeldet wird (ObReferenceObject). Der PnP-Manager entfernt den Verweis bei Bedarf.
Ein Funktions- oder Filtertreiber sollte darauf vorbereitet sein, dieses IRP für ein Gerät jederzeit zu verarbeiten, nachdem seine AddDevice- Routine für das Gerät abgeschlossen wurde. Bustreiber sollten darauf vorbereitet sein, eine Abfrage für BusRelations unmittelbar nach der Aufzählung eines Geräts zu verarbeiten.
Allgemeine Regeln zum Behandeln Plug and Play minor IRPs finden Sie unter Plug and Play.
In den folgenden Unterabschnitten werden die spezifischen Aktionen für die Behandlung der verschiedenen Abfragen beschrieben.
BusRelations Request
Wenn der PnP-Manager die Busbeziehungen (untergeordnete Geräte) eines Adapters oder Controllers abfragt, muss der Bustreiber eine Liste der Zeiger auf die PDOs aller Geräte zurückgeben, die physisch auf dem Bus vorhanden sind. Der Busfahrer meldet alle Geräte, unabhängig davon, ob sie gestartet wurden. Möglicherweise muss der Bustreiber sein Busgerät einschalten, um festzustellen, welche Kinder vorhanden sind.
Warnung Ein Geräteobjekt kann nicht an eine Routine übergeben werden, die einen PDO als Argument akzeptiert, bis der PnP-Manager einen Geräteknoten (devnode) für dieses Objekt erstellt. (Wenn der Treiber ein Geräteobjekt übergibt, überprüft das System Fehlerüberprüfung 0xCA: PNP_DETECTED_FATAL_ERROR.) Der PnP-Manager erstellt die Devnode als Reaktion auf die IRP_MN_QUERY_DEVICE_RELATIONS Anforderung. Der Treiber kann sicher davon ausgehen, dass der Devnode des PDO erstellt wurde, wenn er eine IRP_MN_QUERY_RESOURCE_REQUIREMENTS Anforderung empfängt.
Der Bustreiber, der auf diese IRP reagiert, ist der Funktionstreiber für den Busadapter oder Controller, nicht der übergeordnete Bustreiber für den Bus, mit dem der Adapter oder Controller verbunden ist. Funktionstreiber für Nicht-Bus-Geräte behandeln diese Abfrage nicht. Solche Treiber übergeben einfach das IRP an den nächsten niedrigeren Treiber. (Siehe folgende Abbildung.) Filtertreiber behandeln diese Abfrage in der Regel nicht.
Unter Windows Vista und späteren Betriebssystemen wird empfohlen, dass Treiber immer das IRP_MN_QUERY_DEVICE_RELATIONS IRP einstiften und die Verarbeitung später abschließen. Mit dieser Reihenfolge kann das System Busbeziehungsabfragen asynchron verarbeiten. (Auf Betriebssystemen vor Windows Vista können Treiber sicher STATUS_PENDING aus ihren Dispatch-Routinen zurückgeben, aber der PnP-Manager überlappt die Busbeziehungsabfrage nicht mit einem anderen Vorgang.)
Das folgende Diagramm zeigt, wie Treiber eine Abfrage für Busbeziehungen behandeln.
Im in der Abbildung gezeigten Beispiel sendet der PnP-Manager eine IRP_MN_QUERY_DEVICE_RELATIONS für BusRelations- an die Treiber für das USB-Hubgerät. Der PnP-Manager fordert eine Liste der untergeordneten Elemente des Hubgeräts an.
Wie bei allen PnP-IRPs sendet der PnP-Manager das IRP an den oberen Treiber im Gerätestapel für das Gerät.
Ein optionaler Filtertreiber kann der oberste Treiber im Stapel sein. Ein Filtertreiber behandelt diese IRP in der Regel nicht; er übergibt das IRP nach unten. Ein Filtertreiber kann dieses IRP z. B. behandeln, wenn der Treiber ein nicht aufzählbares Gerät auf dem Bus verfügbar macht.
Der USB-Hubbustreiber verarbeitet das IRP.
Der USB-Hubbustreiber:
Erstellt einen PDO für jedes untergeordnete Gerät, das noch nicht über eins verfügt.
Markiert die PDO für alle Geräte, die nicht mehr im Bus vorhanden sind. Der Bustreiber löscht solche PDOs nicht.Weitere Informationen zum Löschen der PDOs finden Sie unter Entfernen eines Geräts.
Meldet alle untergeordneten Geräte, die im Bus vorhanden sind.
Für jedes untergeordnete Gerät verweist der Bustreiber auf die PDO und legt einen Zeiger auf die PDO in der DEVICE_RELATIONS-Struktur.
In diesem Beispiel gibt es zwei PDOs: eines für das Joystickgerät und eines für das Tastaturgerät.
Der Busfahrer sollte prüfen, ob bereits ein anderer Treiber eine DEVICE_RELATIONS Struktur für dieses IRP erstellt hat. Wenn ja, muss der Busfahrer den vorhandenen Informationen hinzufügen.
Wenn kein untergeordnetes Gerät auf dem Bus vorhanden ist, legt der Treiber die Anzahl in der DEVICE_RELATIONS Struktur auf Null fest und gibt Erfolg zurück.
Legt die entsprechenden Werte im E/A-Statusblock fest und übergibt das IRP an den nächsten niedrigeren Treiber. Der Bustreiber für den Adapter oder Controller schließt das IRP nicht ab.
Ein optionaler niedrigerer Filter, falls vorhanden, behandelt diese IRP in der Regel nicht. Ein solcher Filtertreiber übergibt das IRP an den Stapel. Wenn ein niedrigerer Filtertreiber dieses IRP behandelt, kann er PDO(n) zur Liste der untergeordneten Geräte hinzufügen, aber er darf keine pdOs löschen, die von anderen Treibern erstellt wurden.
Der übergeordnete Bustreiber behandelt dieses IRP nicht, es sei denn, er ist der einzige Treiber im Gerätestapel (das Gerät befindet sich im unformatierten Modus). Wie bei allen PnP IRPs schließt der übergeordnete Bustreiber das IRP mit IoCompleteRequestab.
Wenn ein oder mehrere Busfiltertreiber im Gerätestapel vorhanden sind, können solche Treiber das IRP auf dem Weg zum Bustreiber und/oder auf dem Weg zum IRP-Gerätestapel zurückhalten (wenn IoCompletion Routinen vorhanden sind). Gemäß den PnP-IRP-Regeln kann ein solcher Treiber PDOs zum IRP auf dem Weg nach unten zum Stapel hinzufügen und/oder die Beziehungsliste auf dem IRP-Weg zurück auf den Stapel ändern (in IoCompletion Routinen).
EjectionRelations-Anforderung
Ein Treiber gibt Zeiger auf PDOs aller Geräte zurück, die beim Auswerfen des angegebenen Geräts physisch aus dem System entfernt werden können. Melden Sie die PDOs von Kindern des Geräts nicht; der PnP-Manager fordert immer an, dass untergeordnete Geräte vor dem übergeordneten Gerät entfernt werden.
Der PnP-Manager sendet ein IRP_MN_EJECT IRP an ein Gerät, das ausgeworfen wird. Der Treiber für ein solches Gerät erhält auch einen Remove IRP. Die Ejection-Beziehungen des Geräts erhalten ein IRP_MN_REMOVE_DEVICE IRP (kein IRP_MN_EJECT IRP).
Nur ein übergeordneter Bustreiber kann auf eine EjectionRelations- Abfrage eines seiner untergeordneten Geräte reagieren. Funktions- und Filtertreiber müssen sie an den nächsten unteren Treiber im Gerätestapel übergeben. Wenn ein Bustreiber dieses IRP als Funktionstreiber für seinen Adapter oder Controller empfängt, führt der Bustreiber die Aufgaben eines Funktionstreibers aus und muss das IRP an den nächsten niedrigeren Treiber übergeben.
PowerRelations-Anforderung
Ab Windows 7 ermöglicht die PowerRelations--Abfrage einem Treiber die Angabe einer Energieverwaltungsbeziehung außerhalb der herkömmlichen Beziehung zwischen einem übergeordneten Bus, der die PnP-Aufzählung und ein aufgezähltes untergeordnetes Gerät auf dem Bus unterstützt. Wenn ein Bustreiber beispielsweise kein untergeordnetes Gerät auf dem Bus aufzählen kann oder ein Gerät ein Untergeordnetes Element von mehr als einem Bus ist, kann die abfrage PowerRelations Abfrage die Leistungsbeziehungen des untergeordneten Geräts mit dem Bus oder den Bussen beschreiben.
Der PnP-Manager gibt eine PowerRelations- Abfrage für ein Gerät aus, wenn der Treiber für das Gerät die IoInvalidateDeviceRelations Routine aufruft und einen Type Parameterwert von PowerRelationsangibt.
Als Reaktion auf diese Abfrage stellt der Treiber für das Zielgerät (d. h. das Gerät, das das Ziel für die Abfrage ist) eine DEVICE_RELATIONS Struktur bereit, die Zeiger auf die PDOs aller anderen Geräte enthält, die vom Power-Manager aktiviert werden müssen, bevor das Zielgerät aktiviert wird. Umgekehrt müssen diese anderen Geräte erst nach dem Deaktivieren des Zielgeräts deaktiviert werden. Der Power Manager verwendet die Informationen aus der Abfrage, um sicherzustellen, dass diese Geräte in der richtigen Reihenfolge aktiviert und deaktiviert sind.
Diese Bestellungsgarantie gilt nur für globale Systemzustandsübergänge, die Übergänge zu und von den Systemstromzuständen S1, S2, S3 (Standbymodus), S4 (Ruhezustand) und S5 (Herunterfahren) umfassen. Die PowerRelations Bestellgarantie gilt nicht für Dx-Geräte-Stromzustandsübergänge, während das System im S0 (ausgeführten) Systemzustand bleibt, außer bei Direct Runtime Power Management (DFx) Übergänge.
Wenn sich das Zielgerät auf dem Gerätepfad für eine spezielle Datei befindet (z. B. die Auslagerungsdatei, die Ruhezustandsdatei oder die Absturzabbilddatei), muss der Treiber für das Zielgerät einen zusätzlichen Schritt ausführen, wenn ein IRP_MN_DEVICE_USAGE_NOTIFICATION IRP verarbeitet wird, in dem InPath-TRUEist. Dieser Treiber muss sicherstellen, dass die Geräte, deren PDOs für die PowerRelations- Abfrage bereitgestellt werden, auch den Gerätepfad für die spezielle Datei unterstützen können. Um diese Unterstützung zu bestätigen, muss der Treiber für das Zielgerät zuerst das IRP_MN_DEVICE_USAGE_NOTIFICATION IRP an jedes dieser Geräte senden, und dieser IRP muss den gleichen UsageNotification.Type wie das Zielgerät angeben. Nur wenn alle Geräte, die diesen IRP erhalten, den IRP mit einem Erfolgsstatuscode abschließen, kann der Treiber für das Zielgerät seine IRP_MN_DEVICE_USAGE_NOTIFICATION IRP erfolgreich abschließen. Andernfalls muss dieser Treiber dieses IRP mit einem Fehlerstatuscode abschließen.
Wenn dieser Treiber einen IRP_MN_DEVICE_USAGE_NOTIFICATION IRP verarbeitet, für den InPath-FALSE-ist, muss der Treiber die IRP_MN_DEVICE_USAGE_NOTIFICATION IRP an dieselbe Gruppe abhängiger Geräte senden, wie bei dem InPath-TRUEist. Der Treiber sollte dieses IRP jedoch nie mit einem Fehlerstatuscode abschließen, wenn InPath-FALSE-ist.
Der Treiber, der auf die PowerRelations--Abfrage reagiert, sollte für Zielgeräteänderungsbenachrichtigungen auf allen Geräten registriert werden, deren PDOs für die PowerRelations--Abfrage bereitgestellt werden. Um sich für diese Benachrichtigungen zu registrieren, kann der Treiber die IoRegisterPlugPlayNotification Routine aufrufen und einen EventCategory Parameterwert von EventCategoryTargetDeviceChangeangeben.
RemovalRelations Request
Ein Treiber gibt Zeiger auf PDOs aller Geräte zurück, deren Treiber entfernt werden müssen, wenn die Treiber für das angegebene Gerät entfernt werden. Melden Sie die PDOs von Kindern des Geräts nicht; Der PnP-Manager fordert bereits das Entfernen untergeordneter Geräte vor dem Entfernen eines Geräts an.
Die Reihenfolge, in der Entfernungsbeziehungen entfernt werden, ist nicht definiert.
Jeder Treiber im Gerätestapel kann diese Art von Beziehungsabfrage verarbeiten. Ein Funktions- oder Filtertreiber behandelt das IRP, bevor er an den nächsten unteren Treiber übergeben wird. Ein Busfahrer übernimmt das IRP und schließt es dann ab.
TargetDeviceRelation-Anforderung
Mit der TargetDeviceRelation-Abfrage kann der PnP-Manager einen Nicht-PnP-Gerätestapel für die PDO im PnP-Gerätestapel abfragen, der die Hardware steuert.
Im Allgemeinen leiten Treiber die IRP_MN_QUERY_DEVICE_RELATIONS IRP nach unten, bis das IRP den unteren Rand eines bestimmten Gerätestapels erreicht. Ein Treiber am unteren Rand eines Nicht-PnP-Stapels leitet dann das IRP an den relevanten PnP-Stapel weiter oder gibt den IRP erneut aus. Beispielsweise kann der PnP-Manager eine TargetDeviceRelation Abfrage an das Geräteobjekt am oberen Rand des Dateisystemstapels senden, bei dem es sich um einen Nicht-PnP-Stapel handelt. Jedes Geräteobjekt im Dateisystemstapel übergibt die Abfrage an das darunter liegende Geräteobjekt, bis die Abfrage das Geräteobjekt am unteren Rand des Stapels erreicht hat. Das niedrigste Geräteobjekt im Stapel würde die TargetDeviceRelation Abfrage an das Geräteobjekt oben im PnP-Speichervolumestapel weiterleiten oder erneut ausgeben, und dann wird die Abfrage an die PDO am unteren Rand des Speichervolumesstapels übergeben.
In der folgenden Liste werden die Situationen zusammengefasst, in denen Sie sicher einen Zeiger auf den PDO am unteren Rand eines PnP-Gerätestapels abrufen können:
Geräteobjekt in einem PnP
Ein Geräteobjekt, das sich in einem PnP-Gerätestapel befindet, informiert sich über die PDO des Stapels, wenn die AddDevice Routine für das Gerät aufgerufen wird. Der Treiber kann den Zeiger sicher auf den PDO zwischenspeichern, wenn die Verwendung des Zeigers ordnungsgemäß mit eingehenden IRP_MN_REMOVE_DEVICE Nachrichten mithilfe der Remove-Sperrroutinen synchronisiert wird.
Geräteobjekt in einem Nicht-PnP-Stapel, nicht am unteren Rand des Stapels
Für ein Geräteobjekt, das sich nicht am unteren Rand eines Nicht-PnP-Stapels befindet, kann ein Treiber eine TargetDeviceRelation- Abfrage senden, um einen Zeiger auf den PDO am unteren Rand des entsprechenden PnP-Gerätestapels abzurufen.
File-Objekt für das Gerät
Aufgrund eines Dateiobjekts für das Gerät kann ein Treiber IoGetRelatedDeviceObject- aufrufen, um das Geräteobjekt abzurufen und dann die Anweisungen im vorherigen Listenelement zu befolgen.
Behandeln des Geräteobjekts
Bei einem Handle für das Geräteobjekt kann ein Treiber ObReferenceObjectByHandle- aufrufen, um das Dateiobjekt für das Gerät abzurufen und dann die Anweisungen im vorherigen Listenelement zu befolgen.
Ein übergeordneter Bustreiber muss eine TargetDeviceRelation-Beziehungsabfrage für seine untergeordneten Geräte verarbeiten. Der Bustreiber verweist auf den PDO des untergeordneten Geräts mit ObReferenceObject und gibt einen Zeiger auf die PDO in der DEVICE_RELATIONS-Struktur zurück. Es gibt nur einen PDO-Zeiger in der Struktur für diesen Beziehungstyp. Der PnP-Manager entfernt den Verweis auf die PDO, wenn der Treiber oder die Anwendung die Registrierung für Benachrichtigungen auf dem Gerät aufgehoben.
Nur ein übergeordneter Bustreiber antwortet auf eine TargetDeviceRelation Abfrage. Funktions- und Filtertreiber müssen sie an den nächsten unteren Treiber im Gerätestapel übergeben. Wenn ein Bustreiber dieses IRP als Funktionstreiber für seinen Adapter oder Controller empfängt, führt der Bustreiber die Aufgaben eines Funktionstreibers aus und muss das IRP an den nächsten niedrigeren Treiber übergeben.
Wenn sich ein Treiber nicht in einem PDO-basierten Stapel befindet, sendet der Treiber eine neue Zielgerätebeziehungsabfrage-IRP an das Dem Dateihandle zugeordnete Geräteobjekt, auf dem der Treiber E/A ausführt.
Senden dieses IRP-
Fahrer dürfen IRP_MN_QUERY_DEVICE_RELATIONS nicht senden, um BusRelationsanzufordern. Treiber sind nicht daran beschränkt, dieses IRP für RemovalRelations oder EjectionRelationszu senden, aber es ist nicht wahrscheinlich, dass ein Treiber dies tun würde.
Treiber können einen Gerätestapel für TargetDeviceRelation-abfragen. Informationen zum Senden von IRPs finden Sie unter Umgang mit IRPs. Die folgenden Schritte gelten speziell für dieses IRP:
Legen Sie die Werte am nächsten I/O-Stapelspeicherort des IRP fest: Legen Sie MajorFunction auf IRP_MJ_PNPfest, legen Sie MinorFunction- auf IRP_MN_QUERY_DEVICE_RELATIONSfest, legen Sie Parameters.QueryDeviceRelations.Type auf TargetDeviceRelationfest, und legen Sie Irp->FileObject auf ein gültiges Dateiobjekt fest.
Initialisieren Sie IoStatus.Status für STATUS_NOT_SUPPORTED.
Wenn ein Treiber dieses IRP gesendet hat, um den PDO als Reaktion auf eine IRP_MN_QUERY_DEVICE_RELATIONS für TargetDeviceRelation zu melden, die der Treiber erhalten hat, meldet der Treiber die PDO und gibt die zurückgegebene Beziehungsstruktur frei, wenn das IRP abgeschlossen ist. Wenn ein Treiber dieses IRP aus einem anderen Grund initiiert hat, gibt der Treiber die Beziehungsstruktur frei, wenn das IRP abgeschlossen ist, und leitet die PDO ab, wenn er nicht mehr benötigt wird.
Anforderungen
Kopfzeile |
Wdm.h (enthalten Wdm.h, Ntddk.h oder Ntifs.h) |
Siehe auch
IoRegisterPlugPlayNotification
IRP_MN_DEVICE_USAGE_NOTIFICATION