Como causar um BSOD no Windows XP e versões mais recentes?

Existe uma maneira de causar programaticamente um BSOD no Windows XP e versões mais recentes? Como?

BTW apenas para esclarecer, isso não é para fins maliciosos. O cliente solicitou a capacidade de desligar / reinicializar um terminal em sua LAN dessa maneira. Quando eu perguntei por que, eles disseram porque é mais rápido que uma reinicialização normal ... :)

(Estou curioso em saber que parte do "programaticamente" essas pessoas não entendem quem migrou isso para Super User. Duh.)

O driver do teclado pode ser dito para causar um BSOD:

HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

ou (para teclados PS / 2 mais antigos)

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

E lá definir um REG_DWORD nomeado CrashOnCtrlScroll para 1.

Após a próxima reinicialização, você pode forçar a tela azul Ctrl + ScrollLk + ScrollLk . O código de verificação de bug, nesse caso, será 0xE2 (MANUALLY_INITIATED_CRASH).

Se vocês realmente quer um método programático, você precisa encontrar um buraco em algum driver nessa máquina ou escrever e instalar um driver simplista que chama KeBugCheck ou KeBugCheckEx.

Diverta-se ;)

Nota: pode ser muito útil causar deliberadamente uma falha como essa para os gravadores de driver ou mesmo ao lidar com malware. Se você configurou seu sistema para criar um despejo de memória completo, você terá uma imagem do sistema em execução que pode ser analisada posteriormente. Considere casos como um deadlock em que um depurador não ajuda necessariamente em todos os casos.

Experimente o NotMyFault!

http://technet.microsoft.com/en-us/sysinternals/bb963901

Não sei exatamente como causar isso, mas eu acredito no Vista e 7, o padrão é desligar a falha do sistema e não mostrar o BSOD.

Geralmente, um BSOD acontece quando algo dá errado dentro do sistema operacional ou hardware. Fazer com que algo dê errado dentro de qualquer um deles é inerentemente difícil, já que autores de sistemas operacionais e fornecedores de hardware não gostam de engenheiros de software ruins fazendo seus produtos parecerem ruins e arruinando a experiência de seus usuários.

Escrever um driver é uma das poucas maneiras de chegar perto o suficiente do sistema operacional e do hardware e causar um erro desse tipo. É claro que a instalação de um driver desse tipo não é algo que você geralmente faz sem o conhecimento intencional e os privilégios administrativos, portanto, usá-lo para fins mal-intencionados é bastante difícil. Com esse tipo de acesso, você poderia fazer muito mais mal sem um BSOD ou algo assim.

Um BSOD é um pânico do kernel. Isso significa que uma parte do kernel, o próprio núcleo do sistema operacional fez algo muito ruim. Talvez rabisquei a memória, talvez tenha executado um código que não deveria ter. Programaticamente, você precisaria obter código no espaço do kernel e, de alguma forma, acioná-lo sob demanda. Um pouco arriscado para um servidor de prod.

As máquinas normais do Windows têm muito estado nos processos e no kernel. Seja qual for a limpeza que você precisa para manter o estado consistente, bem, você acabou de curto-circuito.

Especificamente um BSOD é (normalmente) um bug de kernel (ou driver), o kernel está em um estado ruim, tão ruim que ele não pode limpar e prefere reinicializar, perdendo qualquer bom estado que tenha apenas porque não sabe o que é bom e o que é ruim. Quaisquer buffers não puderam ser liberados para o (s) disco (s). Em seguida, ele tentará limpar a reinicialização, mas perdeu muito contexto no desligamento / pânico, por isso será uma limpeza conservadora, tendo que escolher entre as sobras boas e ruins do pânico.

Então, algumas das suas vantagens no desligamento se foram na inicialização, já que agora ele precisa descobrir de onde veio as pernas cortadas debaixo de si mesmo. Ele precisa executar o chkdsk e limpar todos os blocos de disco que estavam em estado de gravação parcial. Os discos USB armazenam muito em cache. Você pode desativar o armazenamento em cache, o que tornaria menos provável a perda de dados em caso de falha, mas, em seguida, o armazenamento em cache não levará um pouco de velocidade. Quais arquivos você está disposto a perder?

Em suma, esta é uma má ideia. Qualquer máquina de produção que tenha isso acontecer pode estar em um estado instável mesmo após a limpeza. Isto é mau.

Eu diria apenas para tomar o hit do desligamento e reiniciar. Você perderá qualquer economia de tempo que ache que obterá na primeira vez em que precisar reconstruir o servidor, porque ele não será inicializado ou seus programas não poderão ser iniciados.

Tem que mencionar que o processo de csrss.exe matando faria BSOD. Mas não no mais novo Windows (8, 8.1).

O trecho de código de https://www.mpgh.net/forum/showthread.php?t=1100477 funciona no Windows 10.17134

#include <windows.h>
#pragma comment(lib, "ntdll.lib")

extern "C" NTSTATUS NTAPI RtlAdjustPrivilege(ULONG Privilege, BOOLEAN Enable, BOOLEAN CurrentThread, PBOOLEAN OldValue);
extern "C" NTSTATUS NTAPI NtRaiseHardError(LONG ErrorStatus, ULONG NumberOfParameters, ULONG UnicodeStringParameterMask,
PULONG_PTR Parameters, ULONG ValidResponseOptions, PULONG Response);

void BlueScreen()
{
    BOOLEAN bl;
    ULONG Response;
    RtlAdjustPrivilege(19, TRUE, FALSE, &bl); // Enable SeShutdownPrivilege
    NtRaiseHardError(STATUS_ASSERTION_FAILURE, 0, 0, NULL, 6, &Response); // Shutdown
}

Parece não haver nenhum traço no log de eventos. Haverá certamente por um traço no minidump embora?