Verificações automáticas

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:

• Reduzindo o IRQL chamando KeLowerIrql

• Reduzindo o IRQL chamando KeRaiseIrql

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

• Alocação ou liberação de pool de páginas com APC_LEVEL IRQL >

• Alocando ou liberando o pool não paginado 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

• Liberação dupla de um bloqueio de rotação.

• Marcando uma solicitação de alocação como obrigatória para sucesso (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 no sistema em todos os casos. O Driver Verifier monitora o comportamento do driver e emite o bug check 0xC4 se ocorrer qualquer uma dessas violações. Consulte Verificação de Bug 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) para obter uma lista dos parâmetros do bug check.

Monitorando a troca 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, uma verificação de bug será emitida. (Esta será a verificação de bug 0xC4 com o primeiro parâmetro igual a 0x90.) A pilha exibida pelo comando de depurador KB geralmente revelará o driver que operou essa operação.

Verificando o descarregamento do driver

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

Em particular, o Verificador de Driver procura:

• Temporizadores não iletados

• Chamadas de procedimento adiado (DPCs) pendentes

• Listas de lookaside não deletadas

• Threads de trabalho não gerenciados

• Filas não deletadas

• Outros recursos semelhantes

Problemas como esses podem potencialmente fazer com que as checagens de falhas do sistema ocorram algum tempo depois que o driver é descarregado, e a causa dessas checagens de falhas pode ser difícil de determinar. Quando o Verificador de Driver estiver ativo, essas violações resultarão na verificação de erros 0xC7 sendo emitida imediatamente após o descarregamento do driver. Consulte Verificação de Bug 0xC7 (TIMER_OR_DPC_INVALID) para obter uma lista dos parâmetros da verificação de bug.

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 possui os indicadores apropriados. Por exemplo, é incorreto chamar MmProbeAndLockPages para um MDL 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 MDL que não está bloqueado.

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

• Chamando MmUnmapLockedPages para um MDL que não está mapeado para um endereço de 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 a verificação de bugs 0xC4 se alguma dessas violações ocorrer. Consulte Bug Check 0xC4 (DRIVER_VERIFIER_DETECTED_VIOLATION) para obter uma lista dos parâmetros do bug check.

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 na memória da sessão.

Os objetos de sincronização devem ser não paginá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 se refere 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 fazer referência a um endereço de memória de sessão de uma sessão diferente tem resultados imprevisíveis, como falhas no 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á um Bug Check 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, com o valor 0xDF para o parâmetro 1.

Alterações de 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 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 iniciará 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 o momento em que o kernel do Windows começa a desligar seus vários subsistemas, como o Registro, o 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á um Verificação de Erro 0xC4: DRIVER_VERIFIER_DETECTED_VIOLATION, com um valor de parâmetro 1 de 0x115, em vez de um 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 que está em execução nesse sistema está funcionando mal. A execução do !analyze -v a partir do depurador de kernel exibe o rastreamento de pilha do thread de trabalho do sistema responsável pelo desligamento. Você deve examinar o stack trace e determinar se a thread de encerramento está bloqueada por um dos drivers que estão sendo testados.

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