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

Se você já viu uma tela azul com mensagens como IRQL_NOT_LESS_OR_EQUAL o DRIVER_IRQL_NÃO_MENOR_OU_IGUAL, você provavelmente já se deparou com um conceito pouco conhecido fora do mundo dos drivers: o IRQL (Interrupt Request Level). Em Windows, esse nível de prioridade de interrupção tem precedência sobre a prioridade de thread quando o sistema está acima de um certo limite, e isso tem consequências diretas na estabilidade.

Nas próximas linhas você encontrará uma guia completo e em espanhol da Espanha sobre o que é o IRQL, como funciona, por que isso causa telas azuis, como diagnosticar o problema com o WinDbg e o que fazer, seja você um usuário que está enfrentando o erro ou desenvolvendo drivers em modo kernel. Vamos ao que interessa.

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

No Windows, o IRQL define a prioridade de Hardwares em que um processador opera a qualquer momento. No Modelo de Driver do Windows (WDM), o código executado em um IRQL baixo pode ser interrompido por código executado em um IRQL mais alto. De fato, em um único computador multi-core, cada CPU pode estar em um IRQL diferente, o que complica a sincronização.

Há uma regra fundamental: Quando uma CPU está sendo executada em um IRQL acima de PASSIVE_LEVEL, ela só pode ser interrompida por atividade em um IRQL ainda maior.Isso organiza a coexistência entre código do usuário, funções do kernel, chamadores adiados (DPCs) e rotinas de serviço de interrupção de dispositivo (ISRs).

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

Em termos gerais, No x86, são utilizados valores de IRQL entre 0 e 31; no x64, entre 0 e 15O 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 executados; APC e falhas de página Geralmente, eles são mapeados para IRQL 1 (APC_LEVEL); IRQL 2 (DISPATCH_LEVEL) abrange o agendador de threads e os DPCs. Acima de DISPATCH_LEVEL, há níveis reservados para interrupções de dispositivos (conhecidas como DIRQL) e outros usos internos, como HIGH_LEVEL.

No ecossistema do motorista, Muitas rotinas comuns são executadas em DISPATCH_LEVEL: por exemplo, DPC e StartIo. Esse design garante que, enquanto um deles estiver acessando filas internas ou outros recursos compartilhados, outra rotina no mesmo nível não o intercepte naquela CPU, pois a regra de preempção só permite interrupções em níveis mais altos.

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

IRQL vs. Prioridade de Thread

É aconselhável não confundir conceitos: A prioridade do thread decide quando o planejador interrompe e qual thread executa; o IRQL controla que tipo de atividade pode ser executada e quais interrupções são mascaradas. Acima de DISPATCH_LEVEL, não há alternância de threads: é o IRQL que controla, não a prioridade das threads.

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 o que devem fazer. As rotinas de despacho para IRPs são executadas em PASSIVE_LEVEL (podem bloquear ou chamar qualquer auxiliar), StartIo e DPC são executadas em DISPATCH_LEVEL para proteger filas compartilhadas, e 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 bugs clássicas associadas a esses problemas são IRQL_NÃO_MENOR_OU_IGUAL (0xA) y DRIVER_IRQL_NÃO_MENOR_OU_IGUAL (0xD1)Ambos indicam uma tentativa de acessar um endereço paginável (ou inválido) em um IRQL muito alto. Isso geralmente ocorre devido a drivers que usam endereços incorretos, desreferenciam ponteiros ruins 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, há padrões que se repetem. Desreferenciando um ponteiro inválido para DISPATCH_LEVEL ou superior Esta é uma receita certa 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 bugs.

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 D1/A, o problema real não é o IRQL em si, mas sim o endereço de memória referenciado. É por isso que os parâmetros 1, 3 e 4 são cruciais para o foco do 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 se vê com o WinDbg, aplicar medidas básicas: Verifique o log do sistema no Visualizador de Eventos em busca de erros que apontem para um dispositivo/driver específico; atualize ou desabilite o driver citado pela 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 RAM. Essas ações, embora simples, eles resolvem um grande número de casos.

Casos da vida real: quando BSODs parecem aleatórios

Um usuário com Windows 10 Pro (CPU AMD Ryzen 5 3400G, GPU NVIDIA Placa-mãe GeForce GTX 1660 Ti e Gigabyte B450 AORUS PRO WIFI, 16 GB de RAM) estava apresentando telas intermitentes de "IRQL_LESS_OR_NOT_EQUAL". Eu já havia atualizado os drivers essenciais (rede, gráficos), instalado todas as atualizações do Windows e executado a ferramenta de memória, tudo 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 é desabilitar temporariamente o software de sobreposição (captura, GPU OSD), drivers periféricos de software agressivos (mouses/teclados com macros) e versões beta de drivers gráficos, e reduza a quantidade de erros. Usar o Verificador de Driver em suspeitos pode ajudar a reduzir o problema com uma pilha mais clara.

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

Outro caso típico: captura de tela com ndis.sys (a camada de rede do Windows). Em um computador real, o sistema travava imediatamente após a inicialização. A solução prática era inicializar em Maneira segura sem funções de rede, abra o Administrador do dispositivo e desabilite os adaptadores em “Adaptadores de rede” para isolar o problema.

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: "Peço desculpas pelo inconveniente. Pode ser um problema de driver, memória ou antivírus. Atualize seus drivers e, se o problema persistir, execute o diagnóstico de memória."Este é um conselho básico, mas válido; no entanto, se os erros persistirem, é uma boa ideia prosseguir com o Verifier e a análise de dump.

Para usuários não técnicos, um protocolo razoável seria: 1) Verifique os eventos do sistema, 2) Atualize os drivers principais (chipset/rede/gráficos), 3) Verifique a RAM com a ferramenta integrada, 4) teste Bota limpar sem software de terceiros que insira ganchos no kernel/GUI e 5) usar o Verifier em drivers de terceiros se nada estiver claro.

Melhores práticas para desenvolvedores de drivers

Se você estiver desenvolvendo e se deparar com D1/A, verifique se o a rotina em execução não está marcada como paginável Não chame funções pagináveis ​​durante a execução em DISPATCH_LEVEL ou superior. Isso inclui evitar referências a dados em seções paginadas e respeitar as restrições de IRQL para auxiliares de 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 pelo qual o Windows ordens interrompem prioridades e certas tarefas internasNo nível arquitetônico, está relacionado a conceitos como “Interrupção”, “Manipulador de interrupção” ou “Nível de prioridade de interrupção” e, em plataformas clássicas, com o Controlador de interrupção programável (PIC)Em outros sistemas, o controle de prioridade é expresso por meio de mecanismos como spl en 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ê é um usuário, concentre-se em drivers e hardware (com Verificador, eventos e testes por padrão). Se você desenvolver, siga rigorosamente as regras de IRQL, memória não paginada e sincronização com bloqueios de rotação. Com as ferramentas certas (WinDbg, Verificador) e leitura cuidadosa dos parâmetros (1, 3 e 4), Essas verificações de bugs não são mais um mistério. e se tornam problemas que podem ser abordados metodicamente.