Is there a way to programmatically cause a BSOD on Windows XP and newer versions? How?
BTW just to clarify, this is not for malicious purposes. The client requested to be able to shut down/reboot a terminal on their LAN this way. When I asked why, they said because it's faster than a normal reboot... :)
(I'm curious which part of "programmatically" do those people not understand who migrated this to Super User. Duh.)
The keyboard driver(s) can be told to cause a BSOD:
HKLM\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters
or (for older PS/2 keyboards)
HKLM\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters
And there set a REG_DWORD named CrashOnCtrlScroll to 1.
After the next reboot you can force the blue screen by Ctrl+ScrollLk+ScrollLk. The bug check code will in this case be 0xE2 (MANUALLY_INITIATED_CRASH).
If you really want a programmatic method, you need to find a hole in some driver on that machine or write and install a simplistic driver that calls either KeBugCheck or KeBugCheckEx.
Have fun ;)
Side-note: it can be very useful to deliberately cause a crash like this for driver writers or even when dealing with malware. If you configured your system to create a full memory dump, you will then have an image of the running system which can be further analyzed. Consider cases like a deadlock where a debugger does not necessarily help in all cases.
The code snippet from https://www.mpgh.net/forum/showthread.php?t=1100477 works on 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
}
There seems to be no trace in the Event Log. There will surely by a trace in the minidump though?
Not sure exactly how to cause it, but I believe in Vista and 7, it defaults to shutting down on system failure and not showing the BSOD.
Generally, a BSOD happens when something goes horribly wrong within the operating system or hardware. Getting something to go wrong within either of those from outside of them is, inherently, rather difficult, as operating system authors and hardware vendors alike don't appreciate bad software engineers making their products look bad and ruining their users' experience.
Writing a driver is one of the few ways to get close enough to the operating system and hardware and cause such an error. Of course, installing such a driver is not something you generally do without purposeful knowledge and administrative privileges, so using this for malicious purposes proves rather difficult. With that kind of access, you could do much more harm without a BSOD or such round about means.
A BSOD is a kernel panic. It means a part of the kernel, the very core of the operating system did something real bad. It maybe scribbled memory, it maybe executed code that it shouldn't have. Programmatically, you'd need to get code in kernel space, and then somehow trigger it on demand. A bit risky for a prod server.
Normal Windows machines have a lot of state in processes and in the kernel. Whatever cleanup you need to keep the state consistent, well you just short circuited it.
Specifically a BSOD is (usually) a kernel (or driver) bug, the kernel is in a bad state, so bad it feels it can't clean up and would rather reboot, losing whatever good state it has just because it doesn't know what's good and what's bad. Any buffers could not get flushed to disk(s). Then it will try to clean up on reboot, but it lost a lot of context on shutdown/panic so it will be a conservative cleanup, having to pick through both good and bad leftovers from the panic.
So, some of your advantage on shutdown is gone on startup, since now it needs to figure out where it got it's legs chopped out from under itself. It needs to run chkdsk and clean up any disk blocks that were in a partial write state. USB disks cache a lot. You can turn off caching which would make it less likely to lose data on crash, but then not caching takes away some speed. Which files are you willing to lose?
In short, this is a bad idea. Any production machine that has this happen may be in an unstable state even after cleanup. This is bad.
I'd say just to take the hit of shutdown and restart. You'll lose whatever time savings you think you get the first time you need to rebuild the server because it won't boot or your programs can't start.
Have to mention that killing csrss.exe process would make BSOD. But not on newest Windows (8, 8.1).
