Jak spowodować BSOD w systemie Windows XP i nowszych wersjach?

Czy istnieje sposób programowego spowodowania BSOD w systemie Windows XP i nowszych wersjach? W jaki sposób?

BTW tylko dla wyjaśnienia, to nie jest do szkodliwych celów. Klient poprosił o możliwość zamknięcia / ponownego uruchomienia terminala w sieci LAN w ten sposób. Kiedy zapytałem dlaczego, powiedzieli, ponieważ jest szybszy niż normalny restart ... :)

(Jestem ciekawy, która część „programowo” nie jest zrozumiała dla osób, które dokonały migracji do Super User. Duh.)

Sterownikom klawiatury można nakazać wywołanie BSOD:

HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

lub (dla starszych klawiatur PS / 2)

HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

I tam ustawiono REG_DWORDnazwę CrashOnCtrlScrollna1 .

Po następnym uruchomieniu możesz wymusić niebieski ekran za pomocą Ctrl+ ScrollLk+ ScrollLk. Kod kontroli błędów będzie w tym przypadku 0xE2 (MANUALLY_INITIATED_CRASH).

Jeśli naprawdę chcesz metodę programową, trzeba znaleźć dziurę w jakimś kierowcą na tym komputerze lub napisać i zainstalować uproszczony sterownik połączenia albo KeBugCheckczyKeBugCheckEx .

Baw się dobrze ;)

Uwaga dodatkowa: celowe spowodowanie takiej awarii może być bardzo użyteczne dla autorów sterowników lub nawet w przypadku złośliwego oprogramowania. Jeśli skonfigurowałeś swój system do tworzenia pełnego zrzutu pamięci, będziesz miał obraz działającego systemu, który będzie mógł być dalej analizowany. Rozważ przypadki takie jak impas, w którym debugger niekoniecznie pomaga we wszystkich przypadkach.

Wypróbuj NotMyFault!

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

Nie wiem dokładnie, jak to spowodować, ale wierzę w Vista i 7, domyślnie wyłącza się w przypadku awarii systemu i nie pokazuje BSOD.

Zasadniczo BSOD ma miejsce, gdy coś strasznie pójdzie nie tak w systemie operacyjnym lub sprzęcie. Znalezienie czegoś, co może pójść nie tak w przypadku tych spoza nich, jest z natury dość trudne, ponieważ autorzy systemów operacyjnych i dostawcy sprzętu nie doceniają złych inżynierów oprogramowania, którzy sprawiają, że ich produkty wyglądają źle i rujnują doświadczenia użytkowników.

Napisanie sterownika jest jednym z niewielu sposobów, aby zbliżyć się wystarczająco do systemu operacyjnego i sprzętu i spowodować taki błąd. Oczywiście instalowanie takiego sterownika nie jest czymś, co zazwyczaj robisz bez celowej wiedzy i uprawnień administracyjnych, więc używanie go do szkodliwych celów jest dość trudne. Przy takim dostępie możesz wyrządzić o wiele więcej szkody bez BSOD lub podobnych środków.

BSOD to panika jądra. Oznacza to część jądra, sam rdzeń systemu operacyjnego zrobił coś naprawdę złego. Być może nabazgrał pamięć, może wykonał kod, którego nie powinien mieć. Programowo musisz uzyskać kod w przestrzeni jądra, a następnie jakoś uruchomić go na żądanie. Trochę ryzykowne dla serwera prod.

Normalne komputery z systemem Windows mają wiele stanów w procesach i jądrze. Niezależnie od tego, jakie porządki potrzebujesz, aby utrzymać spójność stanu, po prostu go zwarłeś.

W szczególności BSOD jest (zwykle) błędem jądra (lub sterownika), jądro jest w złym stanie, tak źle, że wydaje się, że nie można go wyczyścić i wolałby zrestartować komputer, tracąc swój dobry stan tylko dlatego, że go nie ma wiedzieć, co jest dobre, a co złe. Żadne bufory nie mogły zostać opróżnione na dyski. Następnie spróbuje oczyścić się przy ponownym uruchomieniu, ale stracił wiele kontekstu przy zamykaniu / panice, więc będzie to konserwatywne czyszczenie, z koniecznością zbierania zarówno dobrych, jak i złych resztek z paniki.

Tak więc część korzyści płynących z zamykania przestała być uruchamiana, ponieważ teraz musi dowiedzieć się, gdzie dostał nogi od siebie. Musi uruchomić program chkdsk i wyczyścić wszystkie bloki dysku, które były w stanie częściowego zapisu. Dyski USB bardzo często buforują. Możesz wyłączyć buforowanie, co zmniejszyłoby ryzyko utraty danych po awarii, ale nie buforowanie zabiera trochę prędkości. Które pliki chcesz stracić?

Krótko mówiąc, to zły pomysł. Każda maszyna produkcyjna, która tak się dzieje, może być niestabilna nawet po czyszczeniu. To jest złe.

Powiedziałbym, żeby wziąć uderzenie zamykania i restartować. Stracisz wszelkie oszczędności czasu, które Twoim zdaniem otrzymasz po raz pierwszy, gdy będziesz musiał odbudować serwer, ponieważ nie można go uruchomić lub nie można uruchomić programów.

Muszę wspomnieć, że zabicie procesu csrss.exe spowodowałoby BSOD. Ale nie w najnowszym systemie Windows (8, 8.1).

Fragment kodu z https://www.mpgh.net/forum/showthread.php?t=1100477 działa w systemie 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
}

Wydaje się, że w dzienniku zdarzeń nie ma śladu. Na pewno jednak ślad w minidump?