14

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.)

Improve this question
13
  • 18
    If you find one that doesn't involve writing a driver, notify Microsoft so they can fix it.
    – Erik
    Mar 4, 2011 at 14:05
  • 13
    Um. It's faster than a normal reboot for a reason - it doesn't necessarily shut down gracefully. If you have a program that shuts down really slowly then it might not be a problem to interrupt it. If you forcibly shut down or abandon anything too close to I/O hardware then you could end up with corrupted filesystems etc. Consider it equivalent to a network-controlled means of cycling the power (which I presume are available for sale, and might solve your problem about as well...)
    – Steve Jessop
    Mar 4, 2011 at 14:20
  • 12
    Your client needs to be institutionalized and his mental conditions followed by a medical team more closely.
    – Darin Dimitrov
    Mar 4, 2011 at 14:21
  • 9
    Ambulances are also generally faster than driving your own car to the hospital. That doesn't make it the preferred mode of travel.
    – FreeAsInBeer
    Mar 4, 2011 at 14:40
  • 8
    Tell your client to press and hold the power button for 6 seconds. Or just jerk the power cord, that's quicker.
    – Hans Passant
    Mar 4, 2011 at 15:03

7 Answers 7

Reset to default
15

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.

Improve this answer
3
  • 4
    Is this true? That's cool if it is! (No, I am not in the mood of testing it on any of my computers.)
    – Andreas Rejbrand
    Mar 4, 2011 at 17:43
  • 3
    Yes, it's actually not meant as a joke. This is something driver writers have been using for some time, although I didn't remember from the top of my head what the registry location was. Had to look it up in my notes.
    – 0xC0000022L
    Mar 4, 2011 at 17:50
  • I experienced a bsod by typing printscreen or by too much memory in using Ram or internal Hardisk. Maybe exploiting a system too.
    – Tech-IO
    Dec 18, 2016 at 15:46
17

Try NotMyFault!

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

Improve this answer
1

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.

Improve this answer
4
  • That's ok, I want that behavior.
    – Tamás Szelei
    Mar 4, 2011 at 14:09
  • 1
    @FreeAsInBeer: Actually that is because your system settings tell it to reboot after the crash. This can be changed in the Advanced tab of your computer properties. Also, the crash dumps created nowadays are usually mini dumps by default, which is why the reboot happens so fast that you don't get to see the blue screen (literally). But it's there, believe me ;)
    – 0xC0000022L
    Mar 4, 2011 at 18:08
  • 1
    @STATUS_ACCESS_DENIED: I know, I was simply letting him know that the default for this variable is set to not show BSOD's, so he knew to check that property if he didn't get one as expected.
    – FreeAsInBeer
    Mar 4, 2011 at 18:16
  • @FreeAsInBeer: fair enough :)
    – 0xC0000022L
    Mar 4, 2011 at 19:15
1

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.

Improve this answer
1

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.

Improve this answer
2
  • You miss the point. There are good reasons to cause a BSOD on demand when debugging a problem with a driver you write. However, I think that this question should never have been migrated from SO to here, because of its nature.
    – 0xC0000022L
    Mar 29, 2012 at 2:26
  • @STATUS_ACCESS_DENIED I agree with your statement, but if you remember at the original question, it had nothing to do with debugging, but a shortcut to shut down a system. Not a good reason in my opinion.
    – Rich Homolka
    Mar 29, 2012 at 17:16
1

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?

Improve this answer
0

Have to mention that killing csrss.exe process would make BSOD. But not on newest Windows (8, 8.1).

Improve this answer
2
  • This can be done by an app. Anyone can make such an app in Visual Studio Express (free).
    – pbies
    May 2, 2014 at 21:17
  • This is code 0xC000021A (STATUS_SYSTEM_PROCESS_TERMINATED), btw.
    – 0xC0000022L
    Dec 19, 2016 at 10:00

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .