Compartir a través de


IRP_MN_QUERY_DEVICE_RELATIONS

El administrador de PnP envía esta solicitud para determinar determinadas relaciones entre dispositivos. Los siguientes tipos de controladores controlan esta solicitud:

  • Los controladores de bus deben controlar busRelations solicitudes de su adaptador o controlador (FDO de bus). Los controladores de filtro pueden controlar las solicitudes de BusRelations.

  • Los controladores de bus deben controlar solicitudes de TargetDeviceRelation para sus dispositivos secundarios (PPO secundarios).

  • Los controladores de función y filtro pueden controlar las solicitudes de RemovalRelations y PowerRelations.

  • Los controladores de autobús pueden controlar EjectionRelations solicitudes de sus dispositivos secundarios (PPO secundarios).

Valor

0x07

Código principal

IRP_MJ_PNP

Cuando se envía

El administrador de PnP envía este IRP para recopilar información sobre los dispositivos con una relación con el dispositivo especificado.

El administrador de PnP consulta el BusRelations de un dispositivo (dispositivos secundarios) cuando el dispositivo se enumera y en otros momentos mientras el dispositivo está activo, como cuando un controlador llama a la IoInvalidateDeviceRelations rutina para indicar que un dispositivo secundario ha llegado o salido.

El administrador de PnP consulta RemovalRelations de un dispositivo antes de quitar los controladores de un dispositivo. El administrador de PnP consulta RemovalRelations y EjectionRelations antes de expulsar un dispositivo.

El administrador de PnP consulta la TargetDeviceRelation de un dispositivo cuando un controlador o una aplicación en modo de usuario se registra para la notificación PnP de un EventCategoryTargetDeviceChange en el dispositivo. El administrador de PnP consulta el dispositivo asociado a un objeto de archivo determinado. IRP_MN_QUERY_DEVICE_RELATIONS es el único IRP de PnP que tiene un parámetro de objeto de archivo válido. Un controlador puede consultar una pila de dispositivos para TargetDeviceRelation. Un controlador no necesita proporcionar un objeto de archivo al enviar su consulta de TargetDeviceRelation.

El administrador de PnP consulta las powerRelations de un dispositivo cuando el controlador del dispositivo llama a IoInvalidateDeviceRelations para indicar que el conjunto de dispositivos con los que este dispositivo tiene una relación implícita de administración de energía ha cambiado. solicitudes de powerRelations se admiten a partir de Windows 7.

Para BusRelations, RemovalRelations, EjectionRelationsy solicitudes de PowerRelations, el administrador de PnP envía IRP_MN_QUERY_DEVICE_RELATIONS en IRQL = PASSIVE_LEVEL en el contexto de un subproceso del sistema.

Para solicitudes de TargetDeviceRelation, el administrador de PnP envía este IRP en IRQL = PASSIVE_LEVEL en un contexto de subproceso arbitrario.

Parámetros de entrada

El Parameters.QueryDeviceRelations.Type miembro de la estructura IO_STACK_LOCATION especifica el tipo de relaciones que se están consultando. Entre los valores posibles se incluyen BusRelations, EjectionRelations, RemovalRelations, TargetDeviceRelationy PowerRelations.

El miembro FileObject de la estructura IO_STACK_LOCATION actual apunta a un objeto de archivo válido solo si Parameters.QueryDeviceRelations.Type es TargetDeviceRelation.

Parámetros de salida

Se devuelve en el bloque de estado de E/S.

Bloque de estado de E/S

Un controlador establece Irp->IoStatus.Status en STATUS_SUCCESS o en un estado de error, como STATUS_INSUFFICIENT_RESOURCES.

Si se ejecuta correctamente, un controlador establece Irp->IoStatus.Information en un puntero de PDEVICE_RELATIONS que apunta a la información de relaciones solicitada. La estructura DEVICE_RELATIONS se define de la siguiente manera:

typedef struct _DEVICE_RELATIONS {
  ULONG  Count;
  PDEVICE_OBJECT  Objects[1];  // variable length
} DEVICE_RELATIONS, *PDEVICE_RELATIONS;

Operación

Si un controlador devuelve relaciones en respuesta a este IRP_MN_QUERY_DEVICE_RELATIONS, el controlador asigna una estructura DEVICE_RELATIONS de la memoria paginada que contiene un recuento y el número adecuado de punteros de objeto de dispositivo. El administrador de PnP libera la estructura cuando ya no se necesita. Si un controlador reemplaza una estructura de DEVICE_RELATIONS que asignó otro controlador, el controlador debe liberar la estructura anterior.

Un controlador debe hacer referencia al PDO de cualquier dispositivo que informe en este IRP (ObReferenceObject). El administrador de PnP quita la referencia cuando corresponda.

Una función o controlador de filtro debe estar preparado para controlar este IRP para un dispositivo en cualquier momento después de que su AddDevice rutina se haya completado para el dispositivo. Los controladores de bus deben estar preparados para controlar una consulta de BusRelations inmediatamente después de enumerar un dispositivo.

Para conocer las reglas generales sobre el control de Plug and Play irP menores, consulte Plug and Play.

En las subsecciones siguientes se describen las acciones específicas para controlar las distintas consultas.

de solicitud BusRelations

Cuando el administrador de PnP consulta las relaciones de bus (dispositivos secundarios) de un adaptador o controlador, el controlador de bus debe devolver una lista de punteros a los PO de cualquier dispositivo que esté físicamente presente en el bus. El controlador de autobús informa de todos los dispositivos, independientemente de si se han iniciado. Es posible que el controlador de autobús tenga que encender su dispositivo de autobús para determinar qué elementos secundarios están presentes.

Advertencia Un objeto de dispositivo no se puede pasar a ninguna rutina que tome un PDO como argumento hasta que el administrador de PnP cree un nodo de dispositivo (devnode ) para ese objeto. (Si el controlador pasa un objeto de dispositivo, el sistema comprobará comprobación de errores 0xCA: PNP_DETECTED_FATAL_ERROR). El administrador de PnP crea el nodo devnode en respuesta a la solicitud IRP_MN_QUERY_DEVICE_RELATIONS. El controlador puede suponer de forma segura que se ha creado el nodo de desarrollo del PDO cuando recibe una solicitud de IRP_MN_QUERY_RESOURCE_REQUIREMENTS.

El controlador de bus que responde a este IRP es el controlador de función para el adaptador o controlador de bus, no el controlador primario del bus al que está conectado el adaptador o controlador. Los controladores de función para dispositivos que no son de bus no controlan esta consulta. Estos controladores simplemente pasan el IRP al siguiente controlador inferior. (Consulte la ilustración siguiente). Normalmente, los controladores de filtro no controlan esta consulta.

En Windows Vista y sistemas operativos posteriores, se recomienda que los controladores siempre lápiz la IRP_MN_QUERY_DEVICE_RELATIONS IRP y completen su procesamiento más adelante. Este orden permite al sistema procesar las consultas de relación de bus de forma asincrónica. (En los sistemas operativos antes de Windows Vista, los controladores pueden devolver STATUS_PENDING de forma segura desde sus rutinas de envío, pero el administrador de PnP no se superpone a la consulta de relación de bus con ninguna otra operación).

En el diagrama siguiente se muestra cómo los controladores controlan una consulta para las relaciones de bus.

diagrama que ilustra a los conductores que controlan una consulta para las relaciones de autobús.

En el ejemplo que se muestra en la ilustración, el administrador de PnP envía un IRP_MN_QUERY_DEVICE_RELATIONS para BusRelations a los controladores del dispositivo del concentrador USB. El administrador de PnP solicita una lista de los elementos secundarios del dispositivo central.

  1. Al igual que con todos los IRP de PnP, el administrador de PnP envía el IRP al controlador superior de la pila de dispositivos para el dispositivo.

  2. Un controlador de filtro opcional podría ser el controlador superior de la pila. Normalmente, un controlador de filtro no controla este IRP; pasa el IRP por la pila. Un controlador de filtro puede controlar este IRP, por ejemplo, si el controlador expone un dispositivo no enumerable en el bus.

  3. El controlador del bus del concentrador USB controla el IRP.

    Controlador del bus del concentrador USB:

    • Crea un PDO para cualquier dispositivo secundario que aún no tenga uno.

    • Marca el PDO inactivo para cualquier dispositivo que ya no esté presente en el bus. El controlador de bus no elimina estos archivos PPO. Para obtener más información sobre cuándo eliminar los PPO, consulte Quitar un dispositivo.

    • Informa de cualquier dispositivo secundario que esté presente en el bus.

      Para cada dispositivo secundario, el controlador de bus hace referencia al PDO y coloca un puntero al PDO en la estructura DEVICE_RELATIONS.

      Hay dos PPO en este ejemplo: uno para el dispositivo joystick y otro para el dispositivo de teclado.

      El controlador de autobús debe comprobar si otro controlador ya creó una estructura de DEVICE_RELATIONS para este IRP. Si es así, el controlador de autobús debe agregar a la información existente.

      Si no hay ningún dispositivo secundario presente en el bus, el controlador establece el recuento en cero en la estructura DEVICE_RELATIONS y devuelve el éxito.

    • Establece los valores adecuados en el bloque de estado de E/S y pasa el IRP al siguiente controlador inferior. El controlador de bus del adaptador o controlador no completa el IRP.

  4. Un filtro inferior opcional, si está presente, normalmente no controla este IRP. Este tipo de controlador de filtro pasa el IRP hacia abajo en la pila. Si un controlador de filtro inferior controla este IRP, puede agregar PDO a la lista de dispositivos secundarios, pero no debe eliminar ningún PDO creado por otros controladores.

  5. El controlador de bus primario no controla este IRP, a menos que sea el único controlador de la pila de dispositivos (el dispositivo está en modo sin procesar). Al igual que con todos los IRP de PnP, el controlador de bus primario completa el IRP con IoCompleteRequest.

    Si hay uno o varios controladores de filtro de bus en la pila de dispositivos, estos controladores pueden controlar el IRP en su camino hacia abajo hasta el controlador de autobús o en la forma de hacer una copia de seguridad de la pila del dispositivo (si hay rutinas de IoCompletion). Según las reglas de IRP de PnP, este controlador puede agregar PNP a IRP en su camino hacia abajo de la pila o modificar la lista de relaciones en el camino de copia de seguridad de la pila de IRP (en rutinas de IoCompletion).

de solicitud de ejectionRelations

Un controlador devuelve punteros a PPO de cualquier dispositivo que se pueda quitar físicamente del sistema cuando se expulsa el dispositivo especificado. No notifique los PPO de los elementos secundarios del dispositivo; El administrador de PnP siempre solicita que los dispositivos secundarios se quiten antes de su dispositivo primario.

El administrador de PnP envía una IRP_MN_EJECT IRP a un dispositivo que se va a expulsar. El controlador de este tipo de dispositivo también recibe un IRP de eliminación. Las relaciones de expulsión del dispositivo reciben un IRP de IRP_MN_REMOVE_DEVICE (no un IRP de IRP_MN_EJECT).

Solo un controlador de bus primario puede responder a una consulta de EjectionRelations para uno de sus dispositivos secundarios. Los controladores de función y filtro deben pasarlo al siguiente controlador inferior de la pila de dispositivos. Si un controlador de bus recibe este IRP como controlador de función para su adaptador o controlador, el controlador de bus realiza las tareas de un controlador de función y debe pasar el IRP al siguiente controlador inferior.

solicitud de PowerRelations

A partir de Windows 7, la consulta de PowerRelations permite a un controlador especificar una relación de administración de energía fuera de la relación convencional entre un bus primario que admita la enumeración PnP y un dispositivo secundario enumerado en el bus. Por ejemplo, si un controlador de bus no puede enumerar un dispositivo secundario en el bus o si un dispositivo es un elemento secundario de más de un bus, la consulta PowerRelations puede describir las relaciones de potencia del dispositivo secundario con el bus o los autobuses.

El administrador de PnP emite una consulta de PowerRelations para un dispositivo cuando el controlador del dispositivo llama a la rutina IoInvalidateDeviceRelations y especifica un valor de parámetro Type de PowerRelations.

En respuesta a esta consulta, el controlador del dispositivo de destino (es decir, el dispositivo que es el destino de la consulta) proporciona una estructura de DEVICE_RELATIONS que contiene punteros a los PPO de cualquier otro dispositivo que el administrador de energía deba activar antes de activar el dispositivo de destino. Por el contrario, estos otros dispositivos deben desactivarse solo después de que el dispositivo de destino esté desactivado. El administrador de energía usa la información de la consulta para garantizar que estos dispositivos están activados y desactivados en el orden correcto.

Esta garantía de ordenación solo se aplica a las transiciones de estado de suspensión del sistema global, que incluyen transiciones hacia y desde el S1, S2, S3 (suspensión), S4 (hibernar) y S5 (apagado) estados de energía del sistema. La garantía de ordenación PowerRelations no se aplica a las transiciones de estado de energía del dispositivo Dx mientras el sistema permanece en el estado del sistema S0 (en ejecución), excepto en el caso de administración de energía en tiempo de ejecución dirigida (DFx) transiciones.

Si el dispositivo de destino está en la ruta de acceso del dispositivo para un archivo especial (como el archivo de paginación, el archivo de hibernación o el archivo de volcado de memoria), el controlador del dispositivo de destino debe realizar un paso adicional cuando controla un IRP de IRP_MN_DEVICE_USAGE_NOTIFICATION en el que InPath es TRUE. Este controlador debe asegurarse de que los dispositivos cuyos PPO se suministran para la powerRelations consulta también pueden admitir estar en la ruta de acceso del dispositivo para el archivo especial. Para confirmar esta compatibilidad, el controlador del dispositivo de destino debe enviar primero el IRP de IRP_MN_DEVICE_USAGE_NOTIFICATION a cada uno de estos dispositivos y este IRP debe especificar el mismo UsageNotification.Type que el dispositivo de destino. Solo si todos los dispositivos que reciben este IRP completan el IRP con un código de estado correcto pueden el controlador para el dispositivo de destino completar su irP de IRP_MN_DEVICE_USAGE_NOTIFICATION correctamente. De lo contrario, este controlador debe completar este IRP con un código de estado de error.

Cuando este mismo controlador controla un IRP de IRP_MN_DEVICE_USAGE_NOTIFICATION para el que inPath es FALSE, el controlador debe enviar el IRP de IRP_MN_DEVICE_USAGE_NOTIFICATION al mismo conjunto de dispositivos dependientes que para el caso en el que InPath es TRUE. Sin embargo, el controlador nunca debe completar este IRP con un código de estado de error cuando InPath es FALSE.

El controlador que responde a la consulta PowerRelations debe registrarse para recibir notificaciones de cambio de dispositivo de destino en todos los dispositivos cuyos PPO se proporcionan para la consulta de PowerRelations. Para registrarse para estas notificaciones, el controlador puede llamar a la rutinaIoRegisterPlugNotification y especificar un valor de parámetro EventCategory de EventCategoryTargetDeviceChange.

solicitud de eliminación de Relations

Un controlador devuelve punteros a PPO de cualquier dispositivo cuyos controladores se deben quitar cuando se quitan los controladores del dispositivo especificado. No notifique los PPO de los elementos secundarios del dispositivo; El administrador de PnP ya solicita la eliminación de dispositivos secundarios antes de quitar un dispositivo.

El orden en el que se quitan las relaciones de eliminación es indefinido.

Cualquier controlador de la pila de dispositivos puede controlar este tipo de consulta de relaciones. Una función o controlador de filtro controla el IRP antes de pasarlo al siguiente controlador inferior. Un controlador de autobús controla el IRP y, a continuación, lo completa.

de solicitud TargetDeviceRelation

La consulta TargetDeviceRelation permite al administrador de PnP consultar una pila de dispositivos que no sea PnP para el PDO en la pila de dispositivos PnP que controla el hardware.

En general, los controladores reenvía la IRP_MN_QUERY_DEVICE_RELATIONS IRP por la pila hasta que el IRP llega a la parte inferior de una pila de dispositivos determinada. Un controlador situado en la parte inferior de una pila que no sea PnP reenvía o vuelve a enviar el IRP a la pila de PnP correspondiente. Por ejemplo, el administrador de PnP podría enviar una consulta TargetDeviceRel ation al objeto de dispositivo en la parte superior de la pila del sistema de archivos, que es una pila que no es PnP. Cada objeto de dispositivo de la pila del sistema de archivos pasaría la consulta al objeto de dispositivo debajo hasta que la consulta llegara al objeto de dispositivo en la parte inferior de la pila. El objeto de dispositivo más bajo de la pila reenviaría o volvería a emitir el TargetDeviceRelation consulta al objeto de dispositivo en la parte superior de la pila de volúmenes de almacenamiento PnP y, a continuación, la consulta se pasaría al PDO en la parte inferior de la pila de volúmenes de almacenamiento.

En la lista siguiente se resumen las situaciones en las que puede adquirir de forma segura un puntero al PDO en la parte inferior de una pila de dispositivos PnP:

  • Objeto device en un PnP

    Un objeto de dispositivo que se encuentra en una pila de dispositivos PnP aprende sobre el PDO de la pila cuando se llama a la rutina deAddDevicedel dispositivo. El controlador puede almacenar en caché de forma segura el puntero al PDO si el uso del puntero está sincronizado correctamente con los mensajes de IRP_MN_REMOVE_DEVICE entrantes mediante las rutinas de eliminación del bloqueo.

  • Objeto de dispositivo en una pila que no es PnP, no en la parte inferior de la pila

    Para un objeto de dispositivo que no está en la parte inferior de una pila que no es PnP, un controlador puede enviar un consulta TargetDeviceRelation para obtener un puntero al PDO en la parte inferior de la pila de dispositivos PnP correspondiente.

  • Objeto de archivo para el dispositivo

    Dado un objeto de archivo para el dispositivo, un controlador puede llamar a IoGetRelatedDeviceObject para obtener el objeto de dispositivo y, a continuación, seguir las instrucciones del elemento de lista anterior.

  • Identificador del objeto de dispositivo

    Dado un identificador al objeto de dispositivo, un controlador puede llamar a ObReferenceObjectByHandle para obtener el objeto de archivo del dispositivo y, a continuación, seguir las instrucciones del elemento de lista anterior.

Un controlador de bus primario debe controlar una consulta de relaciones de TargetDeviceRelation para sus dispositivos secundarios. El controlador de bus hace referencia al PDO del dispositivo secundario con ObReferenceObject y devuelve un puntero al PDO en la estructura DEVICE_RELATIONS. Solo hay un puntero PDO en la estructura para este tipo de relación. El administrador de PnP quita la referencia al PDO cuando el controlador o la aplicación anula el registro de notificación en el dispositivo.

Solo un controlador de bus primario responde a una consulta de TargetDeviceRelation. Los controladores de función y filtro deben pasarlo al siguiente controlador inferior de la pila de dispositivos. Si un controlador de bus recibe este IRP como controlador de función para su adaptador o controlador, el controlador de bus realiza las tareas de un controlador de función y debe pasar el IRP al siguiente controlador inferior.

Si un controlador no está en una pila basada en PDO, el controlador envía un nuevo IRP de consulta de relación de dispositivo de destino al objeto de dispositivo asociado al identificador de archivo en el que el controlador realiza E/S.

enviar este IRP

Los controladores no deben enviar IRP_MN_QUERY_DEVICE_RELATIONS para solicitar BusRelations. Los controladores no están restringidos a enviar este IRP para RemovalRelations o EjectionRelations, pero no es probable que un controlador lo haga.

Los controladores pueden consultar una pila de dispositivos para TargetDeviceRelation. Consulte control de IRP para obtener información sobre cómo enviar IRP. Los pasos siguientes se aplican específicamente a este IRP:

  • Establezca los valores de la siguiente ubicación de pila de E/S del IRP: establezca majorFunction en IRP_MJ_PNP, establezca MinorFunction en IRP_MN_QUERY_DEVICE_RELATIONS, establezca Parámetro.s.QueryDeviceRelations.Type a TargetDeviceRelationy establezca Irp->FileObject en un objeto de archivo válido.

  • Inicialice ioStatus.Status en STATUS_NOT_SUPPORTED.

Si un controlador envió este IRP para obtener el PDO para informar en respuesta a un IRP_MN_QUERY_DEVICE_RELATIONS para TargetDeviceRelation que recibió el controlador, el controlador notifica el PDO y libera la estructura de relaciones devuelta cuando se completa el IRP. Si un controlador inició este IRP por otro motivo, el controlador libera la estructura de relaciones cuando el IRP finaliza y desreferencia el PDO cuando ya no es necesario.

Requisitos

Cabecera

Wdm.h (incluya Wdm.h, Ntddk.h o Ntifs.h)

Consulte también

AddDevice

IoCompleteRequest

IoGetRelatedDeviceObject

IoInvalidateDeviceRelations

IoRegisterPlugPlayNotification

IRP_MJ_PNP

IRP_MN_DEVICE_USAGE_NOTIFICATION

IRP_MN_EJECT

IRP_MN_QUERY_RESOURCE_REQUIREMENTS

IRP_MN_REMOVE_DEVICE

IO_STACK_LOCATION

ObReferenceObject de

obReferenceObjectByHandle