Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este tópico descreve como portar um driver do User-Mode Driver Framework (UMDF) 1 para UMDF 2. Você pode começar com um driver UMDF 1 que usa arquivos Sources/Dirs (não um projeto do Visual Studio) ou você pode converter um driver UMDF 1 que está contido em um projeto do Visual Studio. O resultado será um projeto de driver UMDF 2 no Visual Studio. Os drivers UMDF 2 são executados no Windows 10 para edições de área de trabalho (Home, Pro, Enterprise e Education) e no Windows 10 Mobile.
O exemplo de driver Echo é um exemplo de um driver que foi portado de UMDF 1 para UMDF 2.
Primeiros passos
Para começar, abra um novo projeto de driver no Visual Studio. Selecione o modelo Visual C++->Windows Driver->WDF->User Mode Driver (UMDF 2). O Visual Studio abre um modelo parcialmente preenchido que inclui stubs para as funções de retorno de chamada que o driver deve implementar. Este novo projeto de driver será a base do seu driver UMDF 2. Use o exemplo UMDF 2 Echo como um guia para o tipo de código que você deve introduzir.
Em seguida, revise o código do driver UMDF 1 existente e determine os mapeamentos de objetos. Cada objeto COM no UMDF 1 tem um objeto WDF correspondente no UMDF 2. Por exemplo, a interface IWDFDevice corresponde ao objeto de dispositivo WDF, que é representado por um handle WDFDEVICE. Quase todos os métodos de interface fornecidos pela estrutura no UMDF 1 têm métodos correspondentes no UMDF 2. Por exemplo, IWDFDevice::GetDefaultIoQueue mapeia para WdfDeviceGetDefaultQueue.
Da mesma forma, as funções de retorno de chamada fornecidas pelo motorista têm equivalentes nas duas versões. No UMDF 1, a convenção de nomenclatura para interfaces fornecidas por driver (exceto IDriverEntry) é IObjectCallbackXxx, enquanto no UMDF 2 a convenção de nomenclatura para rotinas fornecidas por driver é EvtObjectXxx. Por exemplo, o método callback IDriverEntry::OnDeviceAdd mapeia para EvtDriverDeviceAdd.
O driver implementa funções de retorno de chamada no UMDF 1 e 2, mas a maneira como o driver fornece ponteiros para os seus retornos de chamada é diferente. No UMDF 1, o driver implementa métodos callback como membros das interfaces fornecidas pelo próprio driver. O driver registra essas interfaces com a estrutura quando cria objetos de estrutura, por exemplo, chamando IWDFDriver::CreateDevice.
No UMDF 2, o driver fornece ponteiros para funções de retorno de chamada fornecidas pelo driver em estruturas de configuração como WDF_DRIVER_CONFIG e WDF_IO_QUEUE_CONFIG.
Gerenciando o tempo de vida do objeto
Os drivers que usam UMDF 1 devem implementar a contagem de referência para determinar quando é seguro excluir objetos. Como a estrutura rastreia referências de objeto em nome do driver, um driver UMDF 2 não precisa contar referências.
No UMDF 2, cada objeto de estrutura tem um objeto pai padrão. Quando um objeto pai é excluído, a estrutura exclui objetos filho associados. Quando o driver chama um método de criação de objeto, como WdfDeviceCreate, ele pode aceitar o pai padrão ou pode especificar um pai personalizado em uma estrutura WDF_OBJECT_ATTRIBUTES . Para obter uma lista de objetos de estrutura e seus objetos pai padrão, consulte Resumo de objetos do Framework.
Inicialização do driver
Um driver UMDF 1 implementa a interface IDriverEntry . No seu método de retorno de chamada IDriverEntry::OnDeviceAdd, o driver normalmente:
- Cria e inicializa uma instância do objeto de callback do dispositivo.
- Cria o novo objeto de dispositivo de estrutura chamando IWDFDriver::CreateDevice.
- Configura as filas do dispositivo e seus objetos de retorno de chamada correspondentes.
- Cria uma instância de uma classe de interface de dispositivo chamando IWDFDevice::CreateDeviceInterface.
Um driver UMDF 2 implementa DriverEntry e EvtDriverDeviceAdd. Na sua rotina DriverEntry, um driver UMDF 2 normalmente chama WDF_DRIVER_CONFIG_INIT para inicializar a estrutura WDF_DRIVER_CONFIG do driver. Em seguida, ele passa essa estrutura para WdfDriverCreate.
Na sua função EvtDriverDeviceAdd, o driver pode fazer o seguinte:
- Preencha a estrutura WDFDEVICE_INIT , que fornece informações usadas para criar o objeto de dispositivo. Para obter mais informações sobre como usar WDFDEVICE_INIT, consulte Criando um objeto de dispositivo da Framework.
- Configure a área de contexto do objeto de dispositivo. Para obter informações sobre como alocar e acessar espaço de contexto para objetos de estrutura, consulte Espaço de contexto de objeto do framework.
- Crie o objeto do dispositivo.
- Especifique manipuladores de solicitação para o objeto de dispositivo.
- Crie filas de E/S.
- Crie interfaces de dispositivo.
- Defina a política de ociosidade do dispositivo e as configurações de despertar, se o objeto do dispositivo possuir a política de energia.
- Crie objetos de interrupção, se o hardware suportar interrupções.
Instalar o seu driver
Quando você cria um novo projeto de driver no Visual Studio, o novo projeto contém um arquivo .inx. Quando você cria seu driver, Visual Studio compila seu arquivo .inx em um arquivo INF que pode ser usado como parte de um pacote de driver.
Enquanto um arquivo INF para um driver UMDF 1 deve incluir um ID de classe de driver, um DriverCLSID não é necessário em um arquivo INF para um driver UMDF 2.
Além disso, embora um driver UMDF 1 deva fazer referência ao coinstalador em seu arquivo INF, nenhuma referência constaller é necessária em um arquivo UMDF 2 INF. Embora uma referência de coinstalador possa aparecer em um arquivo INF para um driver UMDF 2, uma não é necessária.
Armazenando o contexto do dispositivo
No UMDF 1, o driver geralmente armazena o contexto do dispositivo em um objeto de retorno de chamada criado pelo driver, por exemplo, especificando membros privados da classe de objeto de retorno de chamada do dispositivo. Como alternativa, um driver UMDF 1 pode chamar o método IWDFObject::AssignContext para registrar o contexto em um objeto de estrutura.
No UMDF 2, a estrutura aloca espaço de contexto com base na estrutura de WDF_OBJECT_ATTRIBUTES opcional que o driver fornece quando chama um método de criação de objeto. Depois de chamar o método create de um objeto, um driver pode chamar WdfObjectAllocateContext uma ou mais vezes para alocar espaço de contexto adicional para um objeto específico. Para as etapas que um driver UMDF 2 deve usar para definir uma estrutura de contexto e um método de acessador, consulte Espaço de contexto de objeto do Framework.
Depurando seu driver
Para depurar um driver UMDF 2, você usará extensões no Wdfkd.dll em vez de Wudfext.dll. Para obter mais informações sobre extensões no Wudfext.dll, consulte Resumo das extensões do depurador no Wdfkd.dll.
No UMDF 2, também é possível obter informações adicionais de depuração do driver através do Inflight Trace Recorder (IFR), conforme descrito em Usando o Inflight Trace Recorder nos drivers KMDF e UMDF 2. Além disso, pode usar o In-flight Recorder (IFR) do próprio framework. Consulte Usar o registo de eventos do Framework.