o que acontece quando o kernel do windows encontra um erro que não pode resolver

Question

Eu ouvi de alguém que se a memória desprotegida vai além de uma parede segura no modo kernel, então o hardware pode ser danificado.

Isso é verdade?

Se não o que acontece quando ocorre um erro no modo kernel?

    

Answer 1

As telas azuis da morte acontecem em situações de erro de kernel. É exatamente por isso que o BSOD é gerado: para proteger contra danos ao hardware, congelando o sistema. 'Erro que não pode resolver' é meio ambíguo. KMODE_EXCEPTION_NOT_HANDLED é geralmente gerado no caso de erros desconhecidos. Você pergunta deve ser mais preciso embora.

    

Answer 2

Escrever na RAM, mesmo dados aleatórios, não danificará o hardware.

• Se o sistema for interrompido ao gravar arquivos ou dados no disco rígido, os dados na unidade poderão ficar inconsistentes. Os dados podem ser perdidos como resultado. Mas não haverá danos físicos ao dispositivo.

• Alguns dispositivos de hardware se parecem com RAM para a CPU. Um exemplo moderno é o "APIC Local", que existe em praticamente todos os CPUs x86 modernos. No entanto, escrever dados aleatórios ou inesperados aqui não causará danos ao hardware, mas provavelmente bloqueará o sistema.

• O software que controla o ventilador do sistema é executado em uma seção da memória chamada "SMRAM". Isso é normalmente completamente inacessível para o sistema operacional. É possível em alguns sistemas reativá-lo, mas gravações em MSRs e memória são necessárias para isso. Se falhar, todos os processadores modernos serão desligados se ficarem superaquecidos de qualquer maneira.

Escrevendo para flash , ou seja, o mesmo flash em que o firmware do sistema (UEFI / BIOS) está presente, pode impedir que o sistema seja inicializado. Tecnicamente, o hardware não está danificado, mas você não conseguirá inicializar seu sistema sem reprogramar fisicamente ou substituir o flash do firmware.

• É possível que um sistema operacional atualize o flash. No entanto, isso requer a implementação de um protocolo para enviar dados para o flash, o que significa que não é tão simples quanto gravar na RAM em algum lugar. Acredito que a maneira como isso é geralmente implementado é que os utilitários de atualização BIOS / UEFI realmente gravam o firmware atualizado em uma área reservada da RAM ou possivelmente flash, então ele é mostrado pelo próprio BIOS na próxima inicialização. O kernel não está em execução durante uma atualização do BIOS / UEFI nesse caso, portanto, não pode fazer nada.

• O UEFI possui variáveis do sistema que podem ser lidas e gravadas e tem um espaço limitado para essas variáveis, além de fornecer uma interface na qual essas variáveis podem ser atualizadas. Houve um problema com algumas placas-mãe, onde gravar mais dados e, em seguida, esse espaço pode conter o firmware seria corrompido e não inicializar o sistema quando reiniciado. Isso não teve nada a ver com uma falha no kernel, mas foi um bug no firmware.

O que acontece durante uma falha no modo kernel? Algo - um manipulador de exceção, uma função dentro de um recurso de kernel do Windows ou driver - chama uma função de API do Windows chamada KeBugCheckEx :

Regardless of the reason for a system crash, the function that actually performs the crash is KeBugCheckEx, documented in the Windows Driver Kit (WDK).

This function takes a stop code (also called a bugcheck code) and four parameters that must be interpreted on a per–stop code basis.

After KeBugCheckEx masks out all interrupts on all processors of the system, it switches the display into a low-resolution VGA graphics mode (one implemented by all Windows-supported video cards), paints a blue background and displays the stop code, followed by some text suggesting what the user can do.

Finally, KeBugCheckEx calls any registered device driver bugcheck callbacks (registered by calling the KeRegisterBugCheckCallback function), allowing drivers an opportunity to stop their devices.

It then calls registered reason callbacks (registered by calling the KeRegisterBugCheckReasonCallback function), which allow drivers to append data to the crash dump or write crash dump information to alternate devices.

Há alguns passos depois disso também (atualizará se eu encontrar uma referência). Resumindo, basicamente desabilita todas as interrupções, chama qualquer driver que queira ser chamado durante uma falha, chama qualquer driver que adicione ou mude para o despejo de memória, depois grava as informações do despejo de memória e pára ou reinicia.