Create BSOD from user mode?

Question

I was getting bored with my XP box one day, so I decided to try some of the answers to this question to see if any of them would cause a BSOD.
They didn't, and they seemed like they would be the most likely to do that, so I was wondering if it is possible to trigger a BSOD from user-mode in C/C++, and if so, how?

You mean, other than by triggering bugs in kernel-mode code? — Michael Petrotta, Aug 12 '11 at 00:55
A blue screen is the Windows kernel response to a bug *in the kernel*. So no, aside from exploiting bugs in the kernel, crashes in user mode are handled differently. — Greg Hewgill, Aug 12 '11 at 01:11
Millions of Windows users went before you, albeit unwittingly. But ably assisted by crappy C or C++ code. There isn't much left. Video drivers are your best shot by a large margin. — Hans Passant, Aug 12 '11 at 01:57

score 14 · Answer 1 · answered Dec 15 '16 at 18:16

It's just this:

#include <iostream>
#include <Windows.h>
#include <winternl.h>
using namespace std;
typedef NTSTATUS(NTAPI *pdef_NtRaiseHardError)(NTSTATUS ErrorStatus, ULONG NumberOfParameters, ULONG UnicodeStringParameterMask OPTIONAL, PULONG_PTR Parameters, ULONG ResponseOption, PULONG Response);
typedef NTSTATUS(NTAPI *pdef_RtlAdjustPrivilege)(ULONG Privilege, BOOLEAN Enable, BOOLEAN CurrentThread, PBOOLEAN Enabled);
int main()
{
    BOOLEAN bEnabled;
    ULONG uResp;
    LPVOID lpFuncAddress = GetProcAddress(LoadLibraryA("ntdll.dll"), "RtlAdjustPrivilege");
    LPVOID lpFuncAddress2 = GetProcAddress(GetModuleHandle("ntdll.dll"), "NtRaiseHardError");
    pdef_RtlAdjustPrivilege NtCall = (pdef_RtlAdjustPrivilege)lpFuncAddress;
    pdef_NtRaiseHardError NtCall2 = (pdef_NtRaiseHardError)lpFuncAddress2;
    NTSTATUS NtRet = NtCall(19, TRUE, FALSE, &bEnabled); 
    NtCall2(STATUS_FLOAT_MULTIPLE_FAULTS, 0, 0, 0, 6, &uResp); 
    return 0;
}

If someone gets an error on line 12, change it to: `LPVOID lpFuncAddress2 = GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtRaiseHardError");` — luke, Jun 19 '21 at 08:58

score 11 · Answer 2 · answered Jun 08 '13 at 19:52

There's the undocumented function NtRaiseHardError.

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Error/NtRaiseHardError.html

http://undocumented.ntinternals.net/UserMode/Undocumented%20Functions/Error/HARDERROR_RESPONSE_OPTION.html

If the fifth parameter is 6 (OptionShutdownSystem), you'll get a BSOD. This requires enabling the shutdown privilege.

score 7 · Accepted Answer · answered Aug 12 '11 at 01:23

It seriously difficult to make a BSOD from user mode unless the user mode program interacts with buggy drivers (may be a particular sequence of operations can reveal the bugs in particular driver) disturbs the driver stack. From user mode, the inputs are validated well before passing to the kernel mode to ensure the stability of the system. Most of the Microsoft API/Drivers have validated well to avoid security issues in the system; so does the driver manufactures.

The best way is to disturb the driver stack, but it's not user mode.

You can create BSOD with NotMyFault SystInternals utility. It fundamentally injects a driver and create the BSOD

http://download.sysinternals.com/Files/Notmyfault.zip

+1 for mentioning MS API/Drivers input validation and for another OTS solution in case it was needed for testing. (gotta love sysinternals.) — shelleybutterfly, Aug 12 '11 at 02:05

score 3 · Answer 4 · answered Aug 12 '11 at 01:04

3

The approach other than bugs is resource exhaustion. An area you could investigate would be to consume all CPU on the machine (run as many threads as you have cores at a real time priority level), and consume a kernel resource and depend on the real-time priority to stop the kernel from cleaning up.

Not sure what a good resource would be though. Lots of outstanding async operations against a device that can't get CPU to clean up? You could at least experiment in that direction.

answered Aug 12 '11 at 01:04

janm

17,976
1
43
61

If you can cause windows to bluescreen from user mode at all then that is a bug in a kernel mode component pure and simple. The kernel ought to be able to withstand resource exhaustion (for some definition of withstand) otherwise it is a potential DOS attack. Same applies to any other kernel - if you can stop the kernel from user mode it is a bug. – Stewart Aug 26 '11 at 09:05
Yes and no. Privileged users are allowed to do things that could disrupt the kernel. Protecting against a DoS attack from an administrator account is different to protecting against a DoS attack from an unprivileged user. Something like starting many asynchronous I/O operations with fragmented OVERLAPPED structure allocation in order to consume the non-paged pool, and then have the kernel fail a page allocation at a critical point is a reasonable avenue for crashing the kernel. I would argue that this is not a kernel bug, but administration failure (and therefore from user mode). – janm Aug 27 '11 at 01:53
Check my answer. You CAN generate Blue Screen from user mode by getting SeShutdownPrivilege then, call NtRaiseHardError with Floating Point exception, for example. Not all exceptions will generate BSODs, but Floating Multiple Faults will. – Петър Петров Dec 01 '17 at 14:15

score 2 · Answer 5 · answered Jan 22 '13 at 09:36

2

You can force a system crash with the keyboard. Your title talks about user mode, I am not sure whether this qualifies as user mode, yet it might be useful.

answered Jan 22 '13 at 09:36

Micha Wiedenmann

19,979
21
92
137

Evan Teran · Answer 6 · 2011-08-12T01:13:36.550

If the operating system has no bugs in it, then it should be impossible to BSOD a machine from user space. At worst, it should just crash the offending application.

However, nothing is perfect. There are bugs in every operating system and every operating system has had bugs which cause a BSOD (or an OOPS as Linux does, or however else a given OS chooses to report an irrecoverable error) that is exploitable from user space.

As far as specifics, it really depends on the nature of the bug. There is no generic answer beyond "yes, it's possible".

For more details, you should look more into OS design, and how paging, ring levels and other techniques can be used to separate processes from each other and kernel space.

an oops is not unrecoverable, a kernel panic is – asu Oct 15 '16 at 18:53 — asu, Oct 15 '16 at 18:53

shelleybutterfly · Answer 7 · 2011-08-12T01:57:00.053

2

Well, BSODs are from unrecoverable errors that happen in kernel mode; there is no way to cause that to happen without triggering a kernel error somehow. In general, if you wanted to do it, you would have to find a flaw in a driver [edit: or as a commenter pointed out, a system call] and exploit that.

Or, you could do what this app does: http://www.nirsoft.net/utils/start_blue_screen.html . Just write your own driver to crash the system any way you want to. :)

The Wikipedia page had some interesting information so I include it for reference: http://en.wikipedia.org/wiki/Blue_Screen_of_Death .

edited Aug 12 '11 at 01:57

answered Aug 12 '11 at 01:02

shelleybutterfly

3,216
15
32

1

writing your own driver isn't exactly "from user-mode" ;-). – Evan Teran Aug 12 '11 at 01:05
1

well to be fair the question was: "so I was wondering if it is possible to trigger a BSOD from user-mode in C/C++" not "is it possible to trigger a BSOD without calling a driver". :P – shelleybutterfly Aug 12 '11 at 01:13
in all seriousness, though, although the real answer is that you can't do it without exploiting some flaw or writing a driver that does it intentionally, i suppose the driver could be useful in some testing scenarios; e.g. you have an application that has to maintain consistency in a written file, and you need to make sure that the file doesn't get corrupted upon a BSOD. i'd hate to be the test engineer doing those tests though. :D – shelleybutterfly Aug 12 '11 at 01:16
well you forget about system calls, which don't necessarily need a "driver", they can be core kernel features... But beyond that, calling a routine in a driver which has a flaw and **writing a driver designed to crash** are two very different things. – Evan Teran Aug 12 '11 at 01:16
well, good point about the syscalls, however it still would require finding an exploitable flaw. but i believe you are entirely incorrect in your next statement, at least as long as the "different" you are referring to is a technical difference. so, yes, they are different in the sense that, for instance, you wouldn't require administrative privileges to install a driver if you exploit an existing hole. but technically, there is no difference. you have simply written a driver **that has one or more flaws intentionally built in.** any BSOD caused by a driver is caused by a flaw in the driver. – shelleybutterfly Aug 12 '11 at 01:55

score 1 · Answer 8 · answered Jun 30 '16 at 13:43

1

Two ways without using drivers:

Using the undocumented function NtRaiseHardError as someone pointed out
Setting a critical process with the undocumented function RtlSetProcessIsCritical then terminating it. Requires the SE_DEBUG_NAME privilege. http://www.codeproject.com/Articles/43405/Protecting-Your-Process-with-RtlSetProcessIsCriti

answered Jun 30 '16 at 13:43

user1304765

247
3
19

1

This works on process quit with CRITICAL_PROCESS_DIED. You can directly use NtRaiseHardError for messages and there was a hack once to even print custom text (no longer works in Windows 10) – Петър Петров Aug 03 '17 at 09:22

score 1 · Answer 9 · answered Oct 18 '18 at 18:50

I found at this link a code that generates a bsod : https://www.mpgh.net/forum/showthread.php?t=1100477

And here's the code (I tried it and it works, you just need to call the BlueScreen() function)

#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
    }

score 0 · Answer 10 · answered Mar 05 '21 at 11:13

0

Just open up Windows run and type C:\con\con

answered Mar 05 '21 at 11:13

Superfudge2020

11
3

That was for Windows 9x, that has been fixed – Anic17 Jun 02 '21 at 15:12

Create BSOD from user mode?

10 Answers10

Linked