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

oKtosiTe
  • 9,408
  • 9
  • 46
  • 70
Tamás Szelei
  • 691
  • 2
  • 12
  • 23
  • 18
    If you find one that doesn't involve writing a driver, notify Microsoft so they can fix it. – Erik Mar 04 '11 at 14:05
  • 3
    Try [this](http://technet.microsoft.com/en-us/sysinternals/bb897558.aspx) from Mark Russinovich. – David Heffernan Mar 04 '11 at 14:10
  • 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...) –  Mar 04 '11 at 14:20
  • 12
    Your client needs to be institutionalized and his mental conditions followed by a medical team more closely. – Darin Dimitrov Mar 04 '11 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 04 '11 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 04 '11 at 15:03
  • I told him it's a crazy idea, that it might harm the hardware etc, but he still wants it. He pays for it, I'll do it, if possible. I did everything in my power to make sure he understands the consequences, and I think he does. – Tamás Szelei Mar 04 '11 at 15:07
  • 1
    @Tamás: Why can't he do as Hans Passant suggests? – Andreas Rejbrand Mar 04 '11 at 17:43
  • Is your client happy to install a device driver?! – David Heffernan Mar 04 '11 at 18:32
  • 1
    @Andreas Rejbrand: it's not exactly programmatically. Which implies that you might be able to remotely trigger it. Personally I'd still go for `ExitWindowsEx`/`InitiateSystemShutdownEx`. What you save on the side of the reboot speed should be minimal *unless* you try to save on the file system checks as well ... – 0xC0000022L Mar 07 '11 at 14:24
  • You must be a contractor... ;) You should educate your client, rather than comply to an absurdly stupid request. – MetalMikester Mar 10 '11 at 11:26
  • I absolutely did. Trust, I did everything in my power to make understand how bad this is. At this point I think he does, but won't admit it so still sticking to the idea :). I told him though that I can't do it. – Tamás Szelei Mar 12 '11 at 14:29
  • Step 1. Open case Step 2. Flick RAM card a couple times – Little Helper Nov 12 '11 at 19:36

7 Answers7

17

Try NotMyFault!

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

ConfusedSushi
  • 271
  • 3
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.

sparrowt
  • 2,433
  • 1
  • 24
  • 23
0xC0000022L
  • 6,819
  • 10
  • 50
  • 82
  • 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 04 '11 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 04 '11 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 '16 at 15:46
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?

zagrimsan
  • 1,070
  • 1
  • 9
  • 21
birdwes
  • 61
  • 1
  • 9
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.

FreeAsInBeer
  • 165
  • 1
  • 5
  • That's ok, I want that behavior. – Tamás Szelei Mar 04 '11 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 04 '11 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 04 '11 at 18:16
  • @FreeAsInBeer: fair enough :) – 0xC0000022L Mar 04 '11 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.

Sion Sheevok
  • 119
  • 2
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.

Rich Homolka
  • 31,057
  • 6
  • 55
  • 80
  • 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 '12 at 02: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 '12 at 17:16
0

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

pbies
  • 2,757
  • 3
  • 21
  • 23