what happens when the windows kernel encounters an error it cannot resolve

Question

I have heard from someone that if unprotected memory goes beyond a safe wall in kernel mode then hardware can be damaged.

Is this true?

If not what does happen when an error does occur in kernel mode?

Answer 1

Blue Screens of Death happen in Kernel Error situations. This is exactly why the BSOD is generated: to protect from hardware damage by freezing the system. 'Error that it cannot resolve' is kind of ambiguous. KMODE_EXCEPTION_NOT_HANDLED is usually generated in the case of unknown errors. You question should be more accurate though.

Answer 2

Writing to RAM, even random data, is not going to damage hardware.

• If the system is interrupted in writing files or data to the hard drive, the data on the drive may be inconsistent. Data may be lost as a result. But there will be no physical damage to the device.

• Some hardware devices look like RAM to the CPU. A modern example is the "Local APIC" which exists in just about all modern x86 CPUs. However, writing random or unexpected data here won't cause hardware damage, but likely just lockup your system.

• Software that controls the system fan runs in a section of memory called "SMRAM." This is normally completely inaccessible to the OS. It's possible on some systems to reactivate it, but writes to MSRs as well as memory are needed to do that. If it fails, all modern CPUs will shut off if they become overheated anyway.

Writing to flash, i.e. the same flash that your system firmware (UEFI/BIOS) is in, may prevent your system from booting. Technically the hardware is not damaged but you will be unable to boot your system without physically reprogramming or replacing the firmware flash.

• It's possible for an OS to update the flash. However, this requires implementing a protocol to send data to the flash, meaning it is not as simple as writing to RAM somewhere. I believe the way it is usually implemented is that BIOS/UEFI update utilities actually write the updated firmware in a reserved area of RAM or possibly flash, then it is flashed by the BIOS itself on the next boot. The kernel is not running during a BIOS/UEFI update in this case so it can't do anything.

• UEFI has system variables that can be read and written, and has a limited space for these variables, and provides an interface where these variables can be updated. There was a problem with some motherboards where writing more data then this space can hold would cause the firmware to be corrupt and not boot the system when restarted. This had nothing to do with a kernel crash, but was a bug in the firmware.

What happens during a kernel mode crash? Something - either an exception handler, a function within a Windows kernel facility, or driver - calls a Windows API function called KeBugCheckEx:

Regardless of the reason for a system crash, the function that actually performs the crash is KeBugCheckEx, documented in the Windows Driver Kit (WDK).

This function takes a stop code (also called a bugcheck code) and four parameters that must be interpreted on a per–stop code basis.

After KeBugCheckEx masks out all interrupts on all processors of the system, it switches the display into a low-resolution VGA graphics mode (one implemented by all Windows-supported video cards), paints a blue background and displays the stop code, followed by some text suggesting what the user can do.

Finally, KeBugCheckEx calls any registered device driver bugcheck callbacks (registered by calling the KeRegisterBugCheckCallback function), allowing drivers an opportunity to stop their devices.

It then calls registered reason callbacks (registered by calling the KeRegisterBugCheckReasonCallback function), which allow drivers to append data to the crash dump or write crash dump information to alternate devices.

There's a couple steps after that as well (will update if I find a reference). Summarizing, basically it disables all interrupts, calls any drivers that wanted to be called during a crash, calls any drivers that add to or change to the crash dump, then it writes the crash dump information and either halts or restarts.