Raw PDO para enviar ioctl para driver de filtro superior (kbfiltr / moufiltr) para ativar / desativar o dispositivo

Question

Eu sou muito novo para desenvolvimento de drivers e tentando escrever um driver de filtro simples que irá ativar ou desativar um dispositivo de teclado ou mouse. Se eu puder fazê-lo funcionar, eu quero usá-lo para desativar o touchpad no meu laptop quando um mouse está conectado. Sei que provavelmente há software lá fora que faz isso já, mas eu estou realmente interessado em drivers de dispositivo e quiser aprender a fazer isso sozinho.

Eu estou usando o kbfiltr e moufiltr exemplos que acompanham o WDK, instalados como drivers de filtro superiores. O exemplo kbfiltr cria um pdo que podem ser enumerados e ligado a um programa de usermode. Isso me permite enviar IOCTLs à DOP que são manipulados por KbFilter_EvtIoDeviceControlForRawPdo . No entanto, quando tento fazer alguma coisa relacionada com o driver de filtro, como chamada em KbFilter_EvtIoInternalDeviceControl para que eu possa fazer algo como

VOID
KbFilter_EvtIoInternalDeviceControl(
    IN WDFQUEUE      Queue,
    IN WDFREQUEST    Request,
    IN size_t        OutputBufferLength,
    IN size_t        InputBufferLength,
    IN ULONG         IoControlCode
    )
    ...
    hDevice = WdfIoQueueGetDevice(Queue);
    devExt = FilterGetData(hDevice);

    switch (IoControlCode) {      
    ...
      case IOCTL_INTERNAL_KEYBOARD_DISCONNECT:
       //
       // Clear the connection parameters in the device extension.
       //
       devExt->UpperConnectData.ClassService = NULL;
       break;
    ...
    }

Eu recebo um BSOD. Não é o código acima, no exemplo de baunilha o conjunto como nulo é comentada, apenas pôr em Kbfilter faz com que o BSOD. Tentei definir a extensão do dispositivo diretamente no DOP, mas isso também faz com que um BSOD, presumivelmente porque é o DOP devExt, não de kbfiltr?

(relacionados: o que é uma boa maneira de começar o rastreamento de pilha de um BSOD Eu estou usando Virtual PC como o meu ambiente de teste e uma construção desenfreada de XPSP3)

Não consigo enviar uma IOCTL_INTERNAL_KEYBOARD_DISCONNECT diretamente para a pilha de driver (eu entendo que os dispositivos de entrada aceitar apenas uma conexão de cada vez?), Portanto, a necessidade do DOP cru. Eu realmente só precisa enviar dois IOCTLs (para ativar e desativar) e eu percebi que eu iria usar apenas a desconexão teclado e ligar uma vez que estes já foram definidos.

Se eu estiver errado sobre qualquer uma dessas hipóteses, por favor avise-me, eu sei que eu realmente sou um noob a isso, mas eu não encontrei muita documentação sobre este tipo de comunicação através de uma DOP.

Answer 1

Ok, eu finalmente resolvido isso e meu motorista está funcionando.

Implementação de um controlador de filtro KMDF :

Graças à Sergius que sugeriram a abordagem COM-porta porque isso me ajudou a configurar WinDbg. Este blog incrível pós explica como obtê-lo configurado rapidamente, basicamente você deixar VPC configurar uma porta cOM como um pipe nomeado, ativar o modo de depuração do kernel do sistema operacional virtualizado, e conectá-lo enquanto ele está inicializando. Então você pode obter todas as mensagens DbgPrint quando o motorista é o carregamento e fazer muito mais, mas apenas as mensagens de rastreamento durante o processo de inicialização foram uma grande ajuda para mim.

Eu acho que meu principal problema estava tentando reutilizar um IOCTL interna em KbFiltr. Esta foi apenas uma má idéia do projeto da minha parte porque eu não entender a diferença entre IOCTL interna e outros IOCTLs - IOCTLS Interno tais como IOCTL_INTERNAL_KEYBOARD_DISCONNECT ter condições de acesso restrito e só deve ser enviado por outros motoristas ou do kernel. Também este artigo KB "Como enviar ioctl para driver de filtro" é um exemplo usando o mesmo dispositivo de controle estrutura, mas é WDM.

De qualquer forma, depois de lutar com o exemplo KbFiltr todo fim de semana, eu finalmente desistiu e começou tudo de novo usando o WDF Torradeira / filtr exemplo . Esta é uma mais barebones KMDF driver de filtro e eu tive que preencher um monte de espaços em branco usando KbFiltr e MouFiltr. O funcionamento do controlador de filtro é semelhante ao Torradeira KbFiltr mas cria um dispositivo de controlo em vez de uma DOP. Ele também define um nome de dispositivo do DOS para o dispositivo de controle para que você possa se comunicar com ele de usermode sem ter que Pinvoke para fazer esse passo. O dispositivo de controle permite o controle de todos os dispositivos que têm o seu driver de filtro carregado apenas por iteração sobre a coleção. A waitlock é usado para sincronizar o acesso à coleção.

Eu também era capaz de simplesmente modificar o arquivo INF (para usar mouse classe em vez de classe Toaster) e aplicá-lo em linha reta fora da caixa na minha máquina de teste sem modificação para o código do driver! é muito mais fácil de começar com algo que está funcionando. Esta página dá uma lista abrangente de coisas que você deve mudar para se adaptar as amostras.

Answer 2

Primeiro de tudo: você pode fazer o que você quer fazer (desativar o touchpad no meu laptop quando um mouse está conectado) no modo de usuário. Será muito mais simples e mais seguro. Olhada Usando funções de instalação de dispositivos e WM_DEVICECHANGE

depurar problemas no seu código: Obter um despejo de memória de BSOD ou configurar uma conexão depurador kernel (usando um porta COM no seu PC virtual redirecionado para um tubo). Consulte ferramentas de depuração para Windows

Divirta-se!