How does the BSoD actually work?

Here you can discuss ReactOS related topics.

Moderator: Moderator Team

Post Reply
User avatar
Fraizeraust
Posts: 234
Joined: Thu Jan 05, 2017 11:46 am
Location: Italy
Contact:

How does the BSoD actually work?

Post by Fraizeraust »

This question popped my mind for several months. As we know, a Blue Screen of Death (BSoD, or bug-check -- technically speaking) occurs when an illegal operation has been detected within the kernel mode side to prevent further data corruption. Whether it is a driver fault, accessing an invalid non-paged memory outside the page area, or a rogue pointer results in a bug-check.

However, how the BSoD works under the hood and its mechanisms are all wonders to me... I assume this code (click me!) is supposed to implement bug-check related functions, constants and structures yet I have no clue what are all these lines of code trying to accomplish (except for the KeBugCheck(), which, as far as I know it halts the system and prints out the following bug-check code but I believe it is more than just that).

This question is mainly targeted to developers but also to anyone who has deep knowledge about NT architecture. Thank you in advance.
a.k.a. GeoB99 -- ReactOS Kernel developer -- My Wiki page
ThFabba
Developer
Posts: 293
Joined: Sun Jul 11, 2010 11:39 am

Re: How does the BSoD actually work?

Post by ThFabba »

KeBugCheckWithTf (which does the actual work) has a relatively straightforward structure if you ignore the large amounts of code that's just special-casing to get the right parameters.
  • L751-1068: Mostly determining bug check parameters
  • L1070-1114: Print message, break into the debugger if present (first break, before callbacks)
  • L1117-1118: Disable interrupts and raise IRQL to the highest level, to disable everything else that may interrupt us on the current processor
  • L1120-1166: Halt all other processors, display the blue screen, enable debugger if it isn't yet. Note the FIXMEs, as we don't have support for crash dumps
  • L1167-1181: If we aren't the first processor to get to this point (or if bug check processing triggers another bug check), try to break into the debugger again, and just send the processor into an infinite loop to stop execution
  • L1183-1186: Call bug check callbacks (drivers can register these, most commonly to add data to the dump for easier triage). Not sure what the Watchdog FIXME is about
  • L1188-1194: Reboot if automatic reboots are enabled (in ROS: never)
  • L1196-1201: Break into the debugger again (after callbacks), and if the debugger tries to continue execution, assert/infinite loop.
The rest of the file deals with bug check callbacks, stack trace dumping, finding/printing the right messages, and actually displaying the blue screen (using boot video functions).

If you have any more specific questions, I can elaborate.
hbelusca
Developer
Posts: 1204
Joined: Sat Dec 26, 2009 10:36 pm
Location: Zagreb, Croatia

Re: How does the BSoD actually work?

Post by hbelusca »

ThFabba nicely described what happens during a BSoD, when the corresponding function that implements it is called.
Let me add one word about when this function is called: it can be called in various ways:
- directly by a driver if this driver detects by itself an anomaly in e.g. its internal data, or when something happened that is not supposed to happen;
- or by the kernel, when a fault trap has been raised and handled by the trap handlers and for some reason normal execution cannot be resumed.
User avatar
Fraizeraust
Posts: 234
Joined: Thu Jan 05, 2017 11:46 am
Location: Italy
Contact:

Re: How does the BSoD actually work?

Post by Fraizeraust »

Thank you Hermes and Thomas, very informative and good answers.

One more question. From what I see, KeBugCheck() and KeBugCheckEx() are the same, the only difference being KeBugCheckEx() supplies additional information (returning four parameters than just the bug-check code). Is KeBugCheckEx() a child function of KeBugCheck() or it's just a function operating on its own?

If it is the latter therefore shouldn't it make sense to just use KeBugCheckEx()? Why has KeBugCheck() been created in the first place (sorry if that sounds a bit dumb but I am curious)? Also, the Ex abbreviation at the end of the function stands for Executive, right?
a.k.a. GeoB99 -- ReactOS Kernel developer -- My Wiki page
learn_more
Developer
Posts: 246
Joined: Fri Dec 19, 2014 10:00 pm

Re: How does the BSoD actually work?

Post by learn_more »

Fraizeraust wrote:Thank you Hermes and Thomas, very informative and good answers.

One more question. From what I see, KeBugCheck() and KeBugCheckEx() are the same, the only difference being KeBugCheckEx() supplies additional information (returning four parameters than just the bug-check code). Is KeBugCheckEx() a child function of KeBugCheck() or it's just a function operating on its own?

If it is the latter therefore shouldn't it make sense to just use KeBugCheckEx()? Why has KeBugCheck() been created in the first place (sorry if that sounds a bit dumb but I am curious)? Also, the Ex abbreviation at the end of the function stands for Executive, right?
Are you seriously asking questions here you could have answered yourself if you would have spent 2 seconds looking at the code?
jimtabor
Developer
Posts: 229
Joined: Thu Sep 29, 2005 3:00 pm

Re: How does the BSoD actually work?

Post by jimtabor »

Most people do not bother to look at the code.
middings
Posts: 1073
Joined: Tue May 07, 2013 9:18 pm
Location: California, USA

Re: How does the BSoD actually work?

Post by middings »

Fraizeraust wrote:(S)houldn't it make sense to just use KeBugCheckEx()? Why has KeBugCheck() been created in the first place (sorry if that sounds a bit dumb but I am curious)? Also, the Ex abbreviation at the end of the function stands for Executive, right?
The 'Ex' suffix on API names is a Microsoft-introduced convention. 'Ex' is described here at Stack Overflow. The 'Ex' suffix indicates a preferred version of the API call that adds extended features to the older version that lacks the 'Ex' suffix. Here is a little bit less truthful but funnier answer about the Microsoft Windows API 'Ex' suffix, also from Stack Overflow.

Microsoft retains the old and new 'Ex' versions to preserve compatibility with code written for earlier versions of Windows.
Often but not always, the Ex version of the API call is implemented as a wrapper function built around the older, non-Ex version.

To avoid derailing this BSOD topic, please ask any additional questions about the Windows 'Ex' functions in a new topic.
Last edited by middings on Tue May 08, 2018 10:55 am, edited 1 time in total.
User avatar
Fraizeraust
Posts: 234
Joined: Thu Jan 05, 2017 11:46 am
Location: Italy
Contact:

Re: How does the BSoD actually work?

Post by Fraizeraust »

@middings: That explains a lot. Thank you for your answer.

@learn_more / @jimtabor: Hey hey, I'm sorry if I did not look up at the whole code.
a.k.a. GeoB99 -- ReactOS Kernel developer -- My Wiki page
Post Reply

Who is online

Users browsing this forum: Ahrefs [Bot] and 42 guests