Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
As rotinas de despacho de um driver para pedidos de IRP_MJ_CREATE e IRP_MJ_CLOSE não fazem mais do que completar o IRP de entrada com STATUS_SUCCESS. Para obter mais informações, consulte Conclusão de IRPs.
As rotinas de despacho de outro driver para solicitações de IRP_MJ_CREATE e IRP_MJ_CLOSE podem fazer mais trabalho, dependendo do driver de dispositivo subjacente ou do dispositivo subjacente. Considere os seguintes cenários:
Ao receber uma solicitação de criação, um driver de classe pode inicializar uma fila interna e enviar uma solicitação IRP_MJ_INTERNAL_DEVICE_CONTROL ao driver de porta correspondente para solicitar informações de configuração do dispositivo ou acesso exclusivo a uma porta do controlador.
O recebimento de IRP_MJ_CLOSE indica que a última referência ao objeto de arquivo associado ao objeto de dispositivo de destino foi removida. Isso implica que todos os identificadores para o objeto de arquivo foram fechados e que as solicitações de E/S pendentes foram concluídas ou canceladas.
Ao receber uma solicitação de criação, um driver de um dispositivo usado com pouca frequência pode chamar MmLockPagableCodeSection para tornar residentes algumas das rotinas de driver que processam outras solicitações IRP_MJ_XXX . Ao receber uma solicitação de fechamento recíproco, o driver pode chamar MmUnlockPagableImageSection para conservar a memória do sistema, para que sua seção de imagem paginável seja paginada ao serem fechados todos os identificadores de objeto de arquivo para o(s) objeto(s) de dispositivo desse driver.
Alguns drivers lidam com solicitações de IRP_MJ_CLOSE apenas por simetria porque, depois de os seus objetos de dispositivo serem abertos por um subsistema protegido ou driver de nível superior, os objetos de dispositivo dos drivers de nível inferior não são fechados até que o sistema propriamente dito se desligue. Por exemplo, os drivers de teclado e mouse configuram objetos de dispositivo que representam dispositivos físicos que devem ser funcionais enquanto o sistema está em execução, portanto, esses drivers podem ter rotinas DispatchClose mínimas para simetria ou podem ter rotinas DispatchCreateClose combinadas.
Se o dispositivo controlado por um driver de nível inferior deve estar disponível para que o sistema continue funcionando, a rotina DispatchClose do driver geralmente não será chamada. Por exemplo, alguns dos drivers de disco do sistema não têm rotina DispatchClose , mas esses drivers geralmente têm rotinas DispatchFlushBuffers e DispatchShutdown para concluir quaisquer operações de E/S de arquivo pendentes antes que o sistema seja desligado.
Embora você possa implementar rotinas separadas de DRIVER_DISPATCH e DispatchClose , os drivers às vezes têm uma única rotina DispatchCreateClose para lidar com solicitações de criação e fechamento.