1

How does a driver cause a BSOD? Some real-life experienced example would be good. I know the basic stuff, like that it happens when the OS encounters a critical error like Divide-Fault. What I wish to know is more technical details related to kernel-memory or kernel-behavior when it encounters the aforementioned errors.

3 Answers 3

7

Consider that the OS's normal course of action when it encounters such a class of errors is to terminate the offending process.

The problem is, what do you do if the error occurs within the kernel boundary? You can't simply kill the kernel, because even if it is possible, that would immediately crash the system, leaving the OS without a way to report what went wrong, reboot (in the absence of for example a kernel-indepdendent kernel watchdog), storing diagnostic data, or anything else that would be considered useful in the face of an OS crash.

So the OS does the second best: it displays and possibly stores diagnostics information first, and then enters some state in which control never passes out of a specific part of the kernel. In effect, the system is then frozen, because nothing else will execute before the system is rebooted. The kernel can execute something like a HLT instruction, enter an infinite loop, disable input interrupts, trigger a system reboot, or do whatever else is appropriate.

Depending on the OS, different things can trigger kernel crashes. One possible example is a page fault while executing with interrupts turned off; another is a kernel call which fails preconditions or sanity checks (this is what IRQL_NOT_LESS_OR_EQUAL is all about, for example). For a list of things which can trigger BSODs in Windows, see for example this list of STOP error codes on Windows 2000 on MSDN.

In this context, it's also important to consider the differences of what runs inside the kernel boundary and thus has the potential to cause a fatal system crash as opposed to simply crashing a single process. Anything that is running outside of the kernel (or more accurately, on Intel, outside of ring 0) can be restricted by the kernel, and this is one big reason why e.g. inter-process memory protection and swapping is even possible or practical (each process is set up in such a way that it can access only its own memory, enforced by the CPU, and any violation causes a page fault which is handled by the kernel and can result in either the requested page being reloaded from swap, or the kernel throwing a memory protection error and terminating the offending process). In a monolithic-kernel OS, lots of things run inside the kernel boundary -- this is often done to improve performance, as context switches into and out of the kernel are particularly expensive, but it puts a huge burden on driver programmers to not screw up, as any error (at an inopportunate time, or ever, depending on the class of error) when executing in kernel mode is system critical. In a microkernel OS, in contrast, only the bare minimum of code runs in ring 0 (or equivalent) -- usually, this is limited to such things as memory management, process scheduling and a few other things that require that level of access to the complete system -- and the remainder runs in user-mode and communicates with the kernel through a well-defined interface. Doing so allows the same access controls as is used for user-land processes to also protect kernel-related code, and with a properly defined interface (e.g., any driver must be able to reinitialize the corresponding hardware on load on a running system, even if the driver has been loaded before and the hardware device is in a potentially unknown state), this can work. The downside is again that all those context switches into and out of the kernel degrade system performance, and that was allegedly one big reason why in Windows NT 4.0 (compared to NT 3.x), Microsoft moved device drivers to execute in ring 0 rather than ring 3.

1
1

In difference to usermode in the kernel all drivers share the same memory. If drivers do wrong things here (accessing invalid memory locations) they effect other components. The kernel detects them and bugckecks (nt!KeBugCheckEx) the system to protect the system and data from being damaged.

*nix-like system do the same in form of a kernel panic.

4
  • 1
    Actually, I'd say that all parts of the kernel share the same memory in the same way that all threads in one userspace process share the same memory, but the real danger is that in kernel mode, the normal access controls that prevent one process from stomping on the memory of another are disabled. That's necessary for the kernel to be able to do at least a part of its job, but it also places a much larger burden on the programmer to not screw up. One of the major architectural changes Microsoft did back in NT 4.0 (compared to 3.51) was to allow drivers to run in ring 0 (kernel mode).
    – user
    Jul 19, 2013 at 21:11
  • @MichaelKjörling - So where these drivers ran prior to NT 4.0 ?
    – Abhineet
    Jul 20, 2013 at 4:47
  • 1
    @Abhineet As I recall, device drivers in NT 3.x executed in ring 3 (user mode, same as userland applications). The reason for moving drivers to ring 0 was to improve performance, but since it also meant that any driver could stomp on the memory of any process, it also had a negative effect on system stability. If drivers run in ring 3, a malfunctioning driver can be unloaded and reloaded if it causes a problem (it just needs to be able to reinitialize the hardware it manages); running them in ring 0 makes it virtually impossible to detect if they are causing a problem.
    – user
    Jul 20, 2013 at 9:20
  • @Abhineet You may want to check out the edit to my answer, where I expand a little on this.
    – user
    Jul 20, 2013 at 9:32
0

There are many different ways that it can cause the BSOD. I've usually experienced these issues when updating drivers which sometimes conflicts with the old driver files if updated wrong. Other times I've noticed corruption during the update. I believe, but don't quote me on this, it could also depend on other hardware and drivers. Example could be older hardware with new hardware and a driver update that no longer supports the older hardware.

1
  • You should have posted this as a comment. I have asked the impact in context of the Kernel-Memory or Kernel-Behavior.
    – Abhineet
    Jul 19, 2013 at 12:50

You must log in to answer this question.

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