Compartilhar via

Verificações automáticas

  • Artigo

O Verificador de Driver executa as verificações a seguir sempre que está verificando um ou mais drivers. Você não pode ativar ou desativar essas verificações. A partir do Windows 10, versão 1709, essas verificações automáticas foram movidas para sinalizadores padrão relevantes. Como resultado, os usuários que habilitam o Verificador de Driver com os sinalizadores padrão não devem ver nenhuma redução nas verificações aplicadas.

Monitorando rotinas de IRQL e memória

O Verificador de Driver monitora o driver selecionado para as seguintes ações proibidas:

  • Gerando IRQL chamando KeLowerIrql

  • Reduzindo o IRQL chamando KeRaiseIrql

  • Solicitando uma alocação de memória zero de tamanho

  • Alocar ou liberar pool de páginas com IRQL > APC_LEVEL

  • Alocando ou liberando pool nãopagado com irql > DISPATCH_LEVEL

  • Tentando liberar um endereço que não foi retornado de uma alocação anterior

  • Tentando liberar um endereço que já foi liberado

  • Adquirir ou liberar um mutex rápido com o IRQL > APC_LEVEL

  • Adquirir ou liberar um bloqueio de rotação com IRQL não é igual a DISPATCH_LEVEL

  • Liberando duas vezes um bloqueio de rotação.

  • Marcando uma solicitação de alocação MUST_SUCCEED. Essas solicitações nunca são permitidas.

Se o Verificador de Driver não estiver ativo, essas violações poderão não causar uma falha imediata do sistema em todos os casos. O Verificador de Driver monitora o comportamento do driver e emite bugs marcar 0xC4 se alguma dessas violações ocorrer. Consulte 0xC4 de Verificação de Bugs (DRIVER_VERIFIER_DETECTED_VIOLATION) para obter uma lista dos parâmetros de marcar de bugs.

Monitorando a alternância de pilha

O Verificador de Driver monitora o uso da pilha pelo driver que está sendo verificado. Se o driver alternar sua pilha e a nova pilha não for uma pilha de threads nem uma pilha DPC, um bug marcar será emitido. (Isso será marcar 0xC4 de bug com o primeiro parâmetro igual a 0x90.) A pilha exibida pelo comando de depurador KB geralmente revelará o driver que executou essa operação.

Verificando o descarregamento do driver

Depois que um driver que está sendo verificado descarrega, o Verificador de Driver executa várias verificações para garantir que o driver tenha sido limpo.

Em particular, o Verificador de Driver procura:

  • Temporizadores não desbloqueados

  • DPCs (chamadas de procedimento adiadas) pendentes

  • Listas lookaside não selecionadas

  • Threads de trabalho não gerenciados

  • Filas não selecionadas

  • Outros recursos semelhantes

Problemas como esses podem potencialmente fazer com que as verificações de bugs do sistema sejam emitidas um tempo após o descarregamento do driver, e a causa dessas verificações de bugs pode ser difícil de determinar. Quando o Verificador de Driver estiver ativo, essas violações resultarão em bugs marcar 0xC7 sendo emitidos imediatamente após o descarregamento do driver. Consulte 0xC7 de Verificação de Bugs (TIMER_OR_DPC_INVALID) para obter uma lista dos parâmetros de marcar de bugs.

Monitoramento do uso da MDL (Lista de Descritores de Memória)

No Windows Vista, o Verificador de Driver também monitora o driver selecionado para as seguintes ações proibidas:

  • Chamando MmProbeAndLockPages ou MmProbeAndLockProcessPages em um MDL que não tem os sinalizadores apropriados. Por exemplo, é incorreto chamar MmProbeAndLockPages para um MDL que foi criado usando MmBuildMdlForNonPagedPool.

  • Chamando MmMapLockedPages em um MDL que não tem os sinalizadores apropriados. Por exemplo, é incorreto chamar MmMapLockedPages para um MDL que já está mapeado para um endereço do sistema ou e MDL que não está bloqueado.

  • Chamando MmUnlockPages ou MmUnmapLockedPages em um MDL parcial, ou seja, e MDL criado usando IoBuildPartialMdl.

  • Chamando MmUnmapLockedPages em um MDL que não é mapeado para um endereço do sistema.

Se o Verificador de Driver não estiver ativo, essas violações poderão não fazer com que o sistema pare de responder imediatamente em todos os casos. O Verificador de Driver monitora o comportamento do driver e emite bugs marcar 0xC4 se alguma dessas violações ocorrer. Consulte 0xC4 de Verificação de Bugs (DRIVER_VERIFIER_DETECTED_VIOLATION) para obter uma lista dos parâmetros de marcar de bugs.

Alocação de objeto de sincronização da memória nonPagedPoolSession

A partir do Windows 7, o Verificador de Driver verifica se há objetos de sincronização da memória da sessão.

Os objetos de sincronização devem ser inpáveis. Eles também devem residir no espaço de endereço virtual global em todo o sistema.

Um driver gráfico pode alocar memória de sessão chamando APIs como EngAllocMem. Ao contrário do espaço de endereço global, o espaço de endereço da sessão é virtualizado para cada sessão do Terminal Server. Isso significa que o mesmo endereço virtual usado no contexto de duas sessões diferentes refere-se a dois objetos diferentes. O kernel do Windows deve ser capaz de acessar objetos de sincronização de qualquer sessão do Terminal Server. Tentar referenciar um endereço de memória de sessão de uma sessão diferente tem resultados imprevisíveis, como falhas do sistema ou corrupção silenciosa dos dados de outra sessão.

A partir do Windows 7, quando um driver verificado inicializa um objeto de sincronização chamando APIs como KeInitializeEvent ou KeInitializeMutex, o Verificador de Driver verifica se o endereço do objeto está dentro do espaço de endereço virtual da sessão. Se o Verificador de Driver detectar esse tipo de endereço incorreto, ele emitirá uma 0xC4 de Verificação de Bugs: DRIVER_VERIFIER_DETECTED_VIOLATION, com um valor de parâmetro 1 de 0xDF.

Alterações do contador de referência de objeto de 0 para 1

A partir do Windows 7, o Verificador de Driver verifica se há classes adicionais de referências de objeto incorretas.

Quando o gerenciador de objetos do kernel do Windows cria um objeto, como um objeto File ou um objeto Thread, o contador de referência do novo objeto é definido como 1. O contador de referência é incrementado por chamadas para APIs como ObReferenceObjectByPointer ou ObReferenceObjectByHandle. O contador de referência é decrementado por cada chamada ObDereferenceObject para o mesmo objeto.

Depois que o contador de referência atingir o valor 0, o objeto se tornará elegível para ser liberado. O gerenciador de objetos pode liberá-lo imediatamente ou pode liberá-lo mais tarde. Chamar ObReferenceObjectByPointer ou ObDereferenceObject e alterar o contador de referência de 0 para 1 significa incrementar o contador de referência de um objeto já liberado. Isso sempre está incorreto porque pode resultar em corromper a alocação de memória de outra pessoa.

Bloqueios ou atrasos de desligamento do sistema

A partir do Windows 7, o Verificador de Driver emitirá uma quebra no depurador de kernel se o desligamento do sistema não terminar 20 minutos após o início. O Verificador de Driver atribui o início do desligamento do sistema como a hora em que o kernel do Windows começa a desligar seus vários subsistemas, como o Registro, Plug And Play ou os subsistemas do gerenciador de E/S.

Se um depurador de kernel não estiver anexado ao sistema, o Verificador de Driver emitirá uma 0xC4 de Verificação de Bugs: DRIVER_VERIFIER_DETECTED_VIOLATION, com um valor de parâmetro 1 de 0x115, em vez desse ponto de interrupção.

Frequentemente, um desligamento do sistema que não pode ser concluído em menos de 20 minutos indica que um dos drivers em execução nesse sistema está com mau funcionamento. A execução de !analyze -v do depurador de kernel exibe o rastreamento de pilha do thread de trabalho do sistema responsável pelo desligamento. Você deve examinar esse rastreamento de pilha e determinar se o thread de desligamento está bloqueado por um dos drivers que estão sendo testados.

Às vezes, o sistema não pode desligar porque está sujeito a testes de estresse pesado, mesmo que todos os drivers estejam funcionando corretamente. O usuário pode optar por continuar a execução após esse ponto de interrupção do Verificador de Driver e marcar se o sistema eventualmente será desligado.