¿Cómo causar un BSOD en Windows XP y versiones más recientes?

¿Hay alguna manera de causar mediante programación un BSOD en Windows XP y versiones más recientes? ¿Cómo?

Por cierto solo para aclarar, esto no es para fines maliciosos. El cliente solicitó poder apagar / reiniciar un terminal en su LAN de esta manera. Cuando pregunté por qué, dijeron porque es más rápido que un reinicio normal ... :)

(Tengo curiosidad por saber qué parte de "programáticamente" no entienden esas personas que migraron esto a Super User. Duh.)

Se puede decir a los controladores de teclado que causen un BSOD:

HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

o (para teclados PS / 2 anteriores)

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

Y allí establece un REG_DWORDnombre CrashOnCtrlScrollpara 1.

Después del próximo reinicio, puede forzar la pantalla azul con Ctrl+ ScrollLk+ ScrollLk. El código de verificación de errores en este caso será 0xE2 (MANUALLY_INITIATED_CRASH).

Si realmente desea un método programático, necesita encontrar un hueco en algún controlador de esa máquina o escribir e instalar un controlador simplista que llame a KeBugChecko KeBugCheckEx.

Que te diviertas ;)

Nota al margen: puede ser muy útil causar deliberadamente un bloqueo como este para los escritores de controladores o incluso cuando se trata de malware. Si configuró su sistema para crear un volcado de memoria completo, tendrá una imagen del sistema en ejecución que puede analizarse más a fondo. Considere casos como un punto muerto donde un depurador no necesariamente ayuda en todos los casos.

¡Prueba NotMyFault!

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

No estoy seguro exactamente cómo causarlo, pero creo en Vista y 7, por defecto se apaga en caso de falla del sistema y no muestra el BSOD.

En general, un BSOD ocurre cuando algo sale terriblemente mal dentro del sistema operativo o hardware. Hacer que algo salga mal dentro de cualquiera de los que están fuera de ellos es, por naturaleza, bastante difícil, ya que los autores de sistemas operativos y los proveedores de hardware no aprecian a los malos ingenieros de software que hacen que sus productos se vean mal y arruinen la experiencia de sus usuarios.

Escribir un controlador es una de las pocas formas de acercarse lo suficiente al sistema operativo y al hardware y causar un error de este tipo. Por supuesto, instalar un controlador de este tipo no es algo que generalmente se hace sin un conocimiento intencional y privilegios administrativos, por lo que usarlo con fines maliciosos resulta bastante difícil. Con ese tipo de acceso, podría hacer mucho más daño sin un BSOD o tal ronda de medios.

Un BSOD es un kernel panic. Significa una parte del núcleo, el núcleo del sistema operativo hizo algo realmente malo. Tal vez garabateó memoria, tal vez ejecutó código que no debería tener. Programáticamente, necesitaría obtener código en el espacio del kernel y luego, de alguna manera, activarlo a pedido. Un poco arriesgado para un servidor prod.

Las máquinas normales de Windows tienen mucho estado en los procesos y en el núcleo. Cualquiera que sea la limpieza que necesite para mantener el estado constante, bueno, simplemente lo cortocircuitó.

Específicamente, un BSOD es (generalmente) un error del kernel (o controlador), el kernel está en mal estado, tan malo que parece que no puede limpiarse y prefiere reiniciar, perdiendo el buen estado que tiene solo porque no Sepa lo que es bueno y lo que es malo. No se pudo vaciar ningún búfer en los discos. Luego intentará limpiar al reiniciar, pero perdió mucho contexto en el apagado / pánico, por lo que será una limpieza conservadora, teniendo que recoger las sobras buenas y malas del pánico.

Por lo tanto, parte de su ventaja en el apagado se ha ido en el inicio, ya que ahora necesita descubrir de dónde sacó sus piernas cortadas por debajo de sí mismo. Necesita ejecutar chkdsk y limpiar los bloques de disco que estaban en un estado de escritura parcial. Los discos USB almacenan mucho en caché. Puede desactivar el almacenamiento en caché, lo que haría que sea menos probable que pierda datos en caso de bloqueo, pero luego no almacenar en caché le quita algo de velocidad. ¿Qué archivos estás dispuesto a perder?

En resumen, esta es una mala idea. Cualquier máquina de producción que ocurra esto puede estar en un estado inestable incluso después de la limpieza. Esto es malo.

Yo diría que solo tome el golpe de apagado y reinicie. Perderá el ahorro de tiempo que cree que obtiene la primera vez que necesita reconstruir el servidor porque no arrancará o sus programas no podrán iniciarse.

Tengo que mencionar que matar el proceso csrss.exe haría BSOD. Pero no en Windows más nuevo (8, 8.1).

El fragmento de código de https://www.mpgh.net/forum/showthread.php?t=1100477 funciona en 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 que no hay rastro en el registro de eventos. ¿Seguramente habrá un rastro en el minidump?