O que é IRQL (Nível de Solicitação de Interrupção) no Windows e como ele se relaciona com BSODs?

Se você já se deparou com uma tela azul com mensagens como IRQL_NOT_LESS_OR_EQUAL ou DRIVER_IRQL_NOT_LESS_OR_EQUAL , provavelmente já ouviu falar de um conceito pouco conhecido fora do mundo dos drivers: IRQL (Interrupt Request Level). No Windows , esse nível de prioridade de interrupção tem precedência sobre a prioridade da thread quando o sistema ultrapassa um determinado limite, e isso tem consequências diretas para a estabilidade.

Nas linhas seguintes, você encontrará um guia completo em espanhol (Espanha) explicando o que é IRQL, como funciona , por que causa telas azuis, como diagnosticar o problema com o WinDbg e o que fazer, seja você um usuário enfrentando o problema ou um desenvolvedor de drivers em modo kernel. Vamos começar.

O que é IRQL (Nível de Solicitação de Interrupção) no Windows?

No Windows, o IRQL define a prioridade de hardware na qual um processador opera em um determinado momento. Dentro do Modelo de Driver do Windows (WDM), o código em execução com um IRQL baixo pode ser interrompido por código em execução com um IRQL mais alto. De fato, em um único computador com múltiplos núcleos, cada CPU pode estar em um IRQL diferente, o que complica a sincronização.

Existe uma regra fundamental: quando uma CPU executa uma IRQL acima de PASSIVE_LEVEL, ela só pode ser interrompida por uma atividade que a exiba em uma IRQL ainda mais alta . Isso rege a coexistência de código de usuário, funções do kernel, chamadas de comando adiadas (DPC) e rotinas de serviço de interrupção (ISRs) do dispositivo.

Níveis e prioridades: PASSIVE_LEVEL, APC_LEVEL, DISPATCH_LEVEL e DIRQL

De modo geral, em x86, são utilizados valores de IRQL entre 0 e 31; em x64, entre 0 e 15. O significado prático é o mesmo: IRQL 0 (PASSIVE_LEVEL) é onde o código normal do usuário e muitas funções do driver são executadas; APC e falhas de página geralmente são mapeadas para IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) engloba o agendador de threads e DPC. Acima de DISPATCH_LEVEL, existem níveis reservados para interrupções de dispositivo (conhecidas como DIRQL) e outros usos internos, como HIGH_LEVEL.

No ecossistema de drivers, muitas rotinas comuns são executadas no nível DISPATCH_LEVEL : por exemplo, DPC e StartIo. Esse design garante que, enquanto uma delas estiver acessando filas internas ou outros recursos compartilhados, outra rotina no mesmo nível não a interrompa nessa CPU, pois a regra de preempção permite interrupções apenas em níveis superiores.

Entre o nível DISPATCH_LEVEL e os níveis de perfil/alto, há espaço para as interrupções de hardware (DIRQL) de cada dispositivo . O IRQL de um dispositivo define sua prioridade em relação a outros dispositivos. Um driver WDM obtém esse DIRQL durante o IRP_MJ_PNP com o IRP_MN_START_DEVICE. Esse IRQL do dispositivo não é um valor global fixo, mas sim o associado à linha de interrupção específica.

IRQL vs. Prioridade de Thread

É importante não confundir esses conceitos: a prioridade da thread determina quando o agendador interrompe a execução e qual thread é executada ; o IRQL controla que tipo de atividade pode ser executada e quais interrupções são mascaradas. Acima de DISPATCH_LEVEL, não há troca de threads: o que importa é o IRQL, e não a prioridade da thread.

IRQL e paginação: o que você não deve fazer

Um efeito imediato do aumento do IRQL é que o sistema não pode lidar com falhas de páginaRegra de ouro: código em DISPATCH_LEVEL ou acima dele não pode causar falhas de página. Na prática, isso significa que essas rotinas e os dados que elas tocam deve residir na memória não paginada. Além disso, certos auxiliares de kernel restringem seu uso com base em IRQL: por exemplo, KeWaitForSingleObject DISPATCH_LEVEL só pode ser chamado se você não estiver bloqueando (tempo limite zero) e, para tempos limite diferentes de zero, você precisa estar abaixo de DISPATCH_LEVEL.

Controle implícito e explícito de IRQL

Na maioria das vezes, o próprio sistema invoca suas rotinas no IRQL correto para a função pretendida. As rotinas de despacho para IRPs são executadas em PASSIVE_LEVEL (podem bloquear ou chamar qualquer função auxiliar), StartIo e DPC são executadas em DISPATCH_LEVEL para proteger filas compartilhadas e as ISRs são executadas em DIRQL.

Se você precisar controlá-lo explicitamente, Você pode aumentar e diminuir o IRQL com KeRaiseIrql y KeLowerIrqlExiste um atalho muito utilizado: KeRaiseIrqlToDpcLevel() retorna o IRQL anterior e deixa você em DISPATCH_LEVEL. Importante: Nunca reduza o IRQL abaixo do valor em que estava quando o sistema o chamou; interromper essa sincronização pode abrir janelas de corrida muito sérias.

Erros de tela azul relacionados a IRQL: IRQL_NOT_LESS_OR_EQUAL e DRIVER_IRQL_NOT_LESS_OR_EQUAL

Duas verificações de erros clássicas associadas a esses problemas são IRQL_NOT_LESS_OR_EQUAL (0xA) e DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1) . Ambas indicam uma tentativa de acessar um endereço paginável (ou inválido) em um IRQL excessivamente alto. Isso geralmente ocorre devido a drivers que usam endereços incorretos, desreferenciam ponteiros inválidos ou executam código paginável em níveis inadequados.

No caso específico de DRIVER_IRQL_NÃO_MENOR_OU_IGUAL (0x000000D1), os parâmetros são muito informativos: 1) endereço de memória referenciado; 2) IRQL naquele momento; 3) tipo de acesso (0 leitura, 1 gravação, 2/8 execução); 4) endereço da instrução que referenciou a memória. Com o depurador, você pode usar ln no parâmetro 4 para liste o símbolo mais próximo e saiba qual função estava sendo executada.

Causas comuns a ter em mente

Além do código específico, existem padrões recorrentes. Desreferenciar um ponteiro inválido para DISPATCH_LEVEL ou superior é uma receita para o desastre. Acessar dados pagináveis ​​nesse nível ou executar código paginável (por exemplo, uma função marcada como paginável) também aciona a verificação de erros.

Outros casos comuns incluem chamar uma função em outro driver que já foi baixado (ponteiro de função pendente) ou invocado indiretamente por meio de um ponteiro de função inválido. Muitas vezes, se o sistema conseguir identificar um módulo, você verá seu nome na própria tela azul, e ele também será salvo em KiBugCheckDriver, acessível com dx KiBugCheckDriver do WinDbg.

Um detalhe prático: na maioria dos casos de D1/A, o problema real não é o IRQL em si , mas o endereço de memória referenciado. É por isso que os parâmetros 1, 3 e 4 são essenciais para direcionar o diagnóstico.

Diagnóstico com WinDbg: Comandos úteis e leitura de parâmetros

Para trabalhar nesses casos, WinDbg é a ferramenta chave, e se o BSOD mencionar ntoskrnl.exe Essas informações fornecem muitas orientações sobre se a falha está no subsistema do kernel. Comece por !analyze -v para obter um resumo da verificação de bugs, da pilha e, se tiver sorte, do módulo envolvido. Se o dump incluir um quadro de captura, .trap coloca você no contexto da CPU com falha.

Os comandos de pilha como k, kb, kc, kd, kp, kP, kv Eles mostram diferentes níveis de detalhes de backtrace. Com ln no parâmetro 4 você pode pular para a instrução que referenciou a memória e obter o símbolo próximo. E se você suspeitar que o nível de prioridade está em execução antes da interrupção, !irql mostra o IRQL salvo para o processador de destino (por exemplo, DISPATCH_LEVEL).

Para analisar a direção do parâmetro 1, !pool Ele informará se pertence a um pool paginado; !address y !pte aprofundar-se no mapeamento de memória dessa área. Você pode usar os comandos de exibição de memória para inspecionar o conteúdo que foi tentado acessar. Finalmente, u, ub, uu permite que você desmonte em torno do endereço do parâmetro 4.

Não se esqueça lm t n para listar módulos carregados y !memusage para o estado geral da memória. Se KiBugCheckDriver tem alguma coisa, dx KiBugCheckDriver Ele retornará o nome do módulo Unicode: em um exemplo típico, “Wdf01000.sys” foi visto como o driver envolvido durante a verificação de bug.

Ferramentas do sistema: Verificador de driver, Visualizador de eventos e diagnósticos

El Verificador de motorista Examina o comportamento dos drivers em tempo real e força erros ao detectar o uso incorreto de recursos (como o pool), gerando uma exceção para isolar a área problemática do código. É iniciado com verifier através do mail simbolo do sistema e é aconselhável selecionar o menor conjunto de drivers possível para evitar adicionar muita sobrecarga.

Se você não estiver usando o WinDbg, tente algumas etapas básicas de solução de problemas : verifique o log do sistema no Visualizador de Eventos em busca de erros que apontem para um dispositivo/driver específico; atualize ou desative o driver mencionado na tela azul; verifique a compatibilidade do hardware com a sua versão do Windows; e use o Diagnóstico de Memória do Windows se suspeitar de um problema na memória RAM. Essas ações simples resolvem muitos casos.

Casos da vida real: quando BSODs parecem aleatórios

Um usuário com Windows 10 Pro (CPU AMD Ryzen 5 3400G, GPU NVIDIA GeForce GTX 1660 Ti , placa-mãe Gigabyte B450 AORUS PRO WIFI , 16 GB de RAM) estava enfrentando telas azuis intermitentes com o erro "IRQL_LESS_OR_NOT_EQUAL". Ele já havia atualizado os drivers essenciais (rede, gráficos), instalado todas as atualizações do Windows e executado a solução de problemas de memória, sem detectar nenhum problema.

Em cenários como este, O próximo passo é analisar os dumps com o WinDbg e procurar padrões: processos envolvidos quando ele cai (por exemplo, explorer.exe), módulos de interface gráfica (win32kfull.sys) e funções como xxxProcessNotifyWinEvent aparecendo na pilha. Embora este módulo seja Windows, o gatilho geralmente é um driver de terceiros (gráficos, entrada, sobreposição, placas de captura) que usa memória em um IRQL inadequado e a falha surge dentro win32k.

A recomendação prática aqui é desativar temporariamente softwares de sobreposição (captura, OSD da GPU), drivers de periféricos com softwares agressivos (mouses/teclados com macros) e versões beta de drivers gráficos, e então isolar o problema. Usar o Verificador de Drivers nos drivers suspeitos pode ajudar a identificar o problema com uma lista mais clara de drivers instalados.

Um padrão de rede muito comum: ndis.sys nem sempre é o culpado

Outro caso típico: uma captura de tela mostrando um erro no ndis.sys (a camada de rede do Windows). Em uma máquina real, o sistema travava imediatamente após a inicialização. A solução prática foi inicializar em Modo de Segurança sem rede, abrir o Gerenciador de Dispositivos e desativar os adaptadores em "Adaptadores de rede" para isolar o problemático.

Naquela equipe havia um Controlador Realtek PCIe GBE Family e um Atheros AR5007G. Ao desativar ambos, detectou-se que a causa real era a athrx.sys (Atheros), embora a tela azul mencionada ndis.sysO dump confirmou isso: a pilha passou por ndis!NdisFreeTimerObject mas o módulo culpado era athrx.sysA correção final foi desinstale o dispositivo e instale os drivers oficiais atualizados Do site do fabricante do Atheros. Moral da história: o módulo citado na tela azul pode fazer parte do subsistema afetado, não da fonte.

Resposta de suporte típica e etapas rápidas para usuários

Em uma troca de suporte genuína, um técnico respondeu: "Lamento o inconveniente. É possível que haja um problema com os drivers, a memória ou o software antivírus. Atualize seus drivers e, se o problema persistir, execute o diagnóstico de memória ." É um conselho básico, mas válido; no entanto, se os erros continuarem, é recomendável prosseguir com o Verificador de Memória e a análise do arquivo de despejo de memória.

Para usuários não técnicos, um protocolo razoável seria: 1) revisar os eventos do sistema, 2) atualizar os drivers principais (chipset/rede/gráficos), 3) verificar a RAM com a ferramenta integrada, 4) tentar uma inicialização limpa sem software de terceiros que insira recursos no kernel/interface gráfica e 5) usar o Verificador de drivers de terceiros se nada parecer claro.

Melhores práticas para desenvolvedores de drivers

Se você estiver desenvolvendo e encontrar o erro D1/A, verifique se a rotina em execução não está marcada como paginável ou se não está chamando funções pagináveis ​​enquanto estiver sendo executada em DISPATCH_LEVEL ou superior. Isso inclui evitar referências a dados em seções paginadas e respeitar as restrições de IRQL dos auxiliares do kernel descritas no DDK.

Para sincronizar dados compartilhados, aplicar a regra "sempre acessar dados compartilhados no mesmo IRQL alto" e usar bloqueios de spin quando apropriado. Em multiprocessadores, o IRQL por si só não garante a exclusão entre diferentes CPUs; os bloqueios de spin elevam o IRQL (para DISPATCH_LEVEL) e coordenam o acesso entre núcleos. Se você precisar operar em registradores de hardware sensíveis, KeSynchronizeExecution ajuda você a executar seções críticas no DIRQL correto.

Quando o plano exige aumentar o IRQL, EUA KeRaiseIrqlToDpcLevel para DISPATCH_LEVEL ou KeRaiseIrql com cuidado, salvando o IRQL anterior e restaurando-o exatamente com KeLowerIrql. Vá abaixo do IRQL de entrada, mesmo que por apenas um instante, É um erro de sincronização grave.

Relação com interrupções e hardware

IRQL é o mecanismo que o Windows usa para gerenciar prioridades de interrupção e certas tarefas internas . No nível arquitetural, está relacionado a conceitos como "Interrupção", "Manipulador de interrupção" e "Nível de prioridade de interrupção" e, em plataformas tradicionais, ao Controlador de Interrupção Programável (PIC) . Em outros sistemas, o controle de prioridade é expresso por meio de mecanismos como o spl no Unix ; a ideia geral é a mesma: quem pode interromper quem.

Dicas avançadas de depuração

Em lixeiras onde a pilha aponta para win32kfull!xxxProcessNotifyWinEvent com verificação de bug 0xA/0xD1, inspecione o contexto com .process y .thread (se disponível), observe processos como explorer.exe en !process 0 1 e verificar sobreposições e drivers de interação da GUI. Muitas vezes o problema É a memória corrompida por um terceiro que surge nessa rota.

Não se esqueça de verificar o IRQL com !irql, e contraste: se você estiver em DISPATCH_LEVEL (2) e o parâmetro 3 indicar leitura/gravação/execução em uma página paginável, você já tem uma pista do porquê ela caiu. Cruze essa pista com ln no parâmetro 4 para obter a função específica.

Entender o que é IRQL e como ele se encaixa na execução do kernel ajuda a separar o ruído dos sinais. Se você for um usuário, concentre-se nos drivers e no hardware (usando o Verificador de IRQL, eventos e testes de eliminação). Se você for um desenvolvedor, siga rigorosamente as regras de IRQL, memória não paginada e sincronização com spin locks. Com as ferramentas certas (WinDbg, Verificador de IRQL) e uma leitura atenta dos parâmetros (1, 3 e 4), essas verificações de erros deixam de ser um mistério e se tornam problemas que podem ser resolvidos metodicamente.