Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

share|improve this question

migrated from stackoverflow.com Mar 4 '11 at 22:52

This question came from our site for professional and enthusiast programmers.

18  
If you find one that doesn't involve writing a driver, notify Microsoft so they can fix it. –  Erik Mar 4 '11 at 14:05
12  
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 '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 4 '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 4 '11 at 14:40
7  
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 '11 at 15:03

6 Answers 6

up vote 14 down vote accepted

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.

share|improve this answer
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 '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 4 '11 at 17:50

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

share|improve this answer
    
This can be done by an app. Anyone can make such an app in Visual Studio Express (free). –  pbies May 2 at 21:17

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.

share|improve this answer
    
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 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 '12 at 17:16

Try NotMyFault!

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

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer
    
That's ok, I want that behavior. –  Tamás Szelei Mar 4 '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 4 '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 4 '11 at 18:16
    
@FreeAsInBeer: fair enough :) –  0xC0000022L Mar 4 '11 at 19:15

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.