Partilhar via


IRP_MN_QUERY_CAPABILITIES

O gerenciador PnP envia esse IRP para obter os recursos de um dispositivo, como se o dispositivo pode ser bloqueado ou ejetado.

Os drivers de função e filtro podem lidar com essa solicitação se alterarem os recursos compatíveis com o driver de barramento. Os drivers de barramento devem lidar com essa solicitação para seus dispositivos filho.

Valor

0x09

Código Principal

IRP_MJ_PNP

Quando é enviado

O gerenciador PnP envia esse IRP para o driver de barramento de um dispositivo imediatamente após o dispositivo ser enumerado. O gerenciador PnP envia esse IRP novamente depois que todos os drivers de um dispositivo iniciam o dispositivo. Um driver pode enviar esse IRP para obter os recursos de um dispositivo.

O gerenciador PnP e os drivers enviam esse IRP no IRQL PASSIVE_LEVEL em um contexto de thread arbitrário.

Parâmetros de Entrada

O membro Parameters.DeviceCapabilities.Capabilities da estrutura IO_STACK_LOCATION aponta para uma estrutura DEVICE_CAPABILITIES que contém informações sobre os recursos do dispositivo.

Parâmetros de saída

Parameters.DeviceCapabilities.Capabilities aponta para a estrutura DEVICE_CAPABILITIES que reflete todas as modificações feitas pelos drivers que lidam com o IRP.

Bloco de status de E/S

Um driver define Irp-IoStatus.Status> como STATUS_SUCCESS ou como um status de erro apropriado, como STATUS_UNSUCCESSFUL.

Se um driver de função ou filtro não lidar com esse IRP, ele chamará IoSkipCurrentIrpStackLocation e passará o IRP para o próximo driver. Esse driver não deve modificar Irp-IoStatus.Status> e não deve concluir o IRP.

Um driver de barramento define Irp-IoStatus.Status> e conclui o IRP.

Operação

Quando um dispositivo é enumerado, mas antes que os drivers de função e filtro sejam carregados para o dispositivo, o gerenciador PnP envia uma solicitação IRP_MN_QUERY_CAPABILITIES para o driver de barramento pai para o dispositivo. O driver de barramento deve definir todos os valores relevantes na estrutura DEVICE_CAPABILITIES e retorná-los ao gerenciador PnP.

Depois que a pilha de dispositivos é criada e os drivers iniciam o dispositivo, o gerenciador PnP envia esse IRP novamente para ser tratado primeiro pelo driver na parte superior da pilha de dispositivos e, em seguida, por cada driver inferior na pilha. Os drivers de função e filtro podem definir uma rotina IoCompletion e lidar com esse IRP em seu caminho de backup da pilha de dispositivos.

Os drivers devem adicionar recursos antes de passar o IRP para o próximo driver inferior.

Os drivers devem remover os recursos depois que todos os drivers inferiores tiverem concluído com o IRP. Normalmente, um driver não remove recursos que foram definidos por outros drivers, mas pode fazer isso se tiver informações especiais sobre os recursos do dispositivo em uma determinada configuração. Consulte Plug and Play para obter informações sobre como adiar o processamento do IRP até que os drivers inferiores sejam concluídos.

Depois que um dispositivo é enumerado e seus drivers são carregados, seus recursos não devem ser alterados. Os recursos de um dispositivo podem ser alterados se o dispositivo for removido e enumerado novamente.

Ao lidar com um IRP IRP_MN_QUERY_CAPABILITIES , o driver que é o gerenciador de política de energia do dispositivo deve definir uma rotina IoCompletion e copiar os recursos de energia do dispositivo, como os mapeamentos de estado de energia S-to-D, no caminho do IRP para fazer backup da pilha do dispositivo. Para determinar os recursos de energia de um dispositivo filho, o driver de barramento pai cria outro IRP de recursos de consulta e envia o IRP para seu driver pai. Consulte Recursos de energia do dispositivo de relatório para obter mais informações.

Se um driver manipular esse IRP, ele deverá verificar o valor DEVICE_CAPABILITIES Version. Se esse valor não for uma versão compatível com o driver, o driver deverá falhar no IRP. Se houver suporte para a versão, o driver deverá verificar o campo Tamanho . Um driver deve definir apenas os campos que estão dentro dos limites da estrutura de recursos que ele recebeu como entrada.

Os drivers que lidam com esse IRP podem definir alguns campos DEVICE_CAPABILITIES , mas não devem definir os campos Tamanho e Versão . Esses campos são definidos apenas pelo componente que enviou o IRP.

Consulte Plug and Play para obter as regras gerais para lidar com IRPs secundários Plug and Play.

Enviando este IRP

Um driver de barramento envia esse IRP para a pilha de dispositivos pai quando ele lida com uma solicitação IRP_MN_QUERY_CAPABILITIES para um de seus dispositivos filho. Além disso, um driver pode enviar esse IRP para obter os recursos do dispositivo para um de seus dispositivos. Um único driver na pilha tem apenas parte das informações de recursos do dispositivo; enviar um IRP para a pilha de dispositivos permite que ele reúna a imagem completa, incluindo modificações por qualquer driver de filtro e assim por diante.

Consulte Manipulando IRPs para obter informações sobre o envio de IRPs. As etapas a seguir se aplicam especificamente a este IRP:

  • Aloque uma estrutura DEVICE_CAPABILITIES do pool paginado e inicialize-a como zeros chamando RtlZeroMemory. Inicialize o Size como sizeof(DEVICE_CAPABILITIES), a Version como 1 e Address e UINumber como -1.

  • Defina os valores no próximo local da pilha de E/S do IRP: defina MajorFunction como IRP_MJ_PNP, defina MinorFunction como IRP_MN_QUERY_CAPABILITIES e defina Parameters.DeviceCapabilities como um ponteiro para a estrutura de DEVICE_CAPABILITIES alocada.

  • Inicialize IoStatus.Status para STATUS_NOT_SUPPORTED.

  • Desaloque o IRP e a estrutura DEVICE_CAPABILITIES quando eles não forem mais necessários.

Requisitos

Cabeçalho

Wdm.h (inclua Wdm.h, Ntddk.h ou Ntifs.h)

Confira também

DEVICE_CAPABILITIES