Come causare un BSOD su Windows XP e versioni più recenti?

C'è un modo per causare a livello di codice un BSOD su Windows XP e versioni più recenti? Come?

A proposito, solo per chiarire, questo non è per scopi dannosi. Il client ha richiesto di essere in grado di arrestare / riavviare un terminale sulla propria LAN in questo modo. Quando ho chiesto perché, hanno detto perché è più veloce di un normale riavvio ... :)

(Sono curioso di sapere quale parte di "programmaticamente" quelle persone non capiscono chi è migrato a Super User. Duh.)

Al driver della tastiera può essere detto di causare un BSOD:

HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

o (per tastiere PS / 2 precedenti)

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

E lì impostare un REG_DWORDnome CrashOnCtrlScrolla 1.

Dopo il successivo riavvio è possibile forzare la schermata blu di Ctrl+ ScrollLk+ ScrollLk. Il codice di controllo bug in questo caso sarà 0xE2 (MANUALLY_INITIATED_CRASH).

Se vuoi davvero un metodo programmatico, devi trovare un buco in alcuni driver su quella macchina o scrivere e installare un driver semplicistico che chiama KeBugChecko KeBugCheckEx.

Divertiti ;)

Nota a margine: può essere molto utile provocare deliberatamente un arresto del genere per gli autori di driver o anche quando si tratta di malware. Se hai configurato il tuo sistema per creare un dump di memoria pieno, avrai un'immagine del sistema in esecuzione che può essere ulteriormente analizzato. Considerare casi come un deadlock in cui un debugger non aiuta necessariamente in tutti i casi.

Prova NotMyFault!

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

Non so esattamente come causarlo, ma credo in Vista e 7, per impostazione predefinita si spegne in caso di errore del sistema e non mostra il BSOD.

In genere, un BSOD si verifica quando qualcosa va terribilmente storto nel sistema operativo o nell'hardware. Ottenere qualcosa di sbagliato all'interno di uno di quelli al di fuori di essi è, intrinsecamente, piuttosto difficile, poiché gli autori del sistema operativo e i fornitori di hardware allo stesso modo non apprezzano i cattivi ingegneri del software che rendono i loro prodotti cattivi e rovinano l'esperienza dei loro utenti.

Scrivere un driver è uno dei pochi modi per avvicinarsi abbastanza al sistema operativo e all'hardware e causare un tale errore. Naturalmente, l'installazione di un tale driver non è qualcosa che generalmente fai senza conoscenza intenzionale e privilegi amministrativi, quindi l'utilizzo di questo per scopi dannosi si rivela piuttosto difficile. Con quel tipo di accesso, potresti fare molto più danno senza un BSOD o un tale giro di mezzi.

Un BSOD è un panico del kernel. Significa una parte del kernel, il vero nucleo del sistema operativo ha fatto qualcosa di veramente brutto. Forse scarabocchiava memoria, forse eseguiva codice che non avrebbe dovuto avere. A livello di programmazione, è necessario ottenere il codice nello spazio del kernel e quindi attivarlo in qualche modo su richiesta. Un po 'rischioso per un server prod.

Le macchine Windows normali hanno molto stato nei processi e nel kernel. Qualunque sia la pulizia di cui hai bisogno per mantenere coerente lo stato, beh, lo hai fatto cortocircuitare.

In particolare un BSOD è (di solito) un bug del kernel (o del driver), il kernel è in uno stato cattivo, così male che sembra che non possa ripulire e preferirebbe riavviare, perdendo qualsiasi stato buono abbia solo perché non lo fa sapere cosa è buono e cosa è male. Eventuali buffer non possono essere scaricati su disco / i. Quindi proverà a ripulire al riavvio, ma ha perso un sacco di contesto su arresto / panico, quindi sarà una pulizia conservativa, dovendo raccogliere dal panico gli avanzi buoni e quelli cattivi.

Quindi, alcuni dei tuoi vantaggi allo spegnimento sono andati all'avvio, dal momento che ora ha bisogno di capire dove sono state tagliate le gambe da sotto se stesso. Deve eseguire chkdsk e ripulire tutti i blocchi del disco che si trovavano in uno stato di scrittura parziale. I dischi USB memorizzano molto nella cache. È possibile disattivare la memorizzazione nella cache, il che renderebbe meno probabile la perdita di dati in caso di arresto anomalo, ma non la memorizzazione nella cache porta via una certa velocità. Quali file sei disposto a perdere?

In breve, questa è una cattiva idea. Qualsiasi macchina di produzione che accada può verificarsi in uno stato instabile anche dopo la pulizia. Questo non va bene.

Direi solo per prendere il colpo di spegnimento e riavviare. Perderai qualsiasi risparmio di tempo pensi di ottenere la prima volta che devi ricostruire il server perché non si avvia o i tuoi programmi non possono avviarsi.

Devo dire che uccidere il processo csrss.exe renderebbe BSOD. Ma non su Windows più recente (8, 8.1).

Lo snippet di codice di https://www.mpgh.net/forum/showthread.php?t=1100477 funziona su 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
}

Sembra che non ci sia traccia nel registro eventi. Ci sarà sicuramente una traccia nel minidump però?