Kernel Panic
A kernel panic is an unrecoverable system error.
Overview
History
Windows used to be very, very unstable (almost every pre-NT kernel versions, and early NT versions). When they crashed, they displayed an error message with white text and blue background. This happened so often, that it made to the pop culture, dubbed "Blue Screen of Death", hence the acronym "BSOD".
Despite the name's origin, BSOD is not unique to Windows, all systems have this feature, but they are usually black instead of blue.
Purpose
The main purpose of a kernel panic screen is to inform the user that an unrecoverable error happened, and they have to reset the computer to continue. Quite often, the crash screen contains low-level information for developers to help debugging.
Such low-level information often includes a textual error message, stack trace and register dumps.
There are at least a few OSes which go a step further, and instead of displaying the debug information provide a built-in debugger which can be used interactively if a system crash happens. For example, Amiga could be debugged remotely using serial connection, and some modern systems start GDB server. In general, systems that have some sort of debugging capability tend to display less information on the crash screen.
For big money corp OSes (running on rack servers and mainframes and alike) it is very common not to display any information, except for a code. The maintainers are supposed to pay insanely huge amounts of money for courses where they get a printed documentation which lists those codes and how to work around each. Luckily, those "big" OSes are well written and very rarely crash.
Atari ST is an example of a minimalistic screen: it displayed 2 to 9 bombs depending on the error. It was a very limited error code system.
Funky side
Because a crash screen by its nature is a sad to see, developers started to put little things on screen to cheer the users up. One of the earliest examples is Amiga's "Guru Meditation", suggesting that the user will need a computer guru to solve the problem. Later they renamed it to "Grim Reaper". Undeniably funnier than a simple "System Crashed".
The reason why Microsoft picked the blue background is that according to shrinks, blue makes people calm.
For OSes with the console metaphor, funny ASCII arts are also very popular, specially among hobby OS developers. This is not uncommon to mainstream either, although most just prints developer debug, some BSDs draw ASCII arts too.
Implementation
To implement a kernel panic in your kernel, you'll have to write a special function. This function must be dependency-free, and must not rely on other parts of your kernel. It must be self-contained, so that it can display the screen regardless which parts of your OS failed. This function is commonly called "kpanic" or "panic", but you can give it any name you like.
On legacy x86 computers, implementing kernel panics is simple, as you can write characters into the video memory at 0xB8000 directly. For a modern PC implementing kernel panics is a little bit more difficult, as the frame buffer has no fixed address, and you have to include a font renderer and your own font too.
For an example, an implementation could load a self-contained kpanic() routine to a fixed address below the 1Meg mark. This module would have a predefined header at the beginning, holding a pointer to the initialization routine, as well as information about the current screen mode. If and when your kernel panics, all it has to do is retrieve this header from this fixed location, grab the initialization address, and jump to it.
A few notes to consider:
- make sure that this memory allocated for this module does not rely upon any part of the kernel. - make sure it is not part of the paging process. i.e: it is identity mapped as physical memory outside the paging system. - save such information as the current video mode's frame buffer, pixel depth, bytes per scan line, etc. - with modern hardware, you will have to render font characters to the screen, since Legacy VGA hardware is no longer present. - remember to update this video information if you ever change the screen mode. - load this module as soon as possible, allowing the kernel to panic during boot if needed.
Explicit Invocation
You can call this kpanic from your kernel when a specific error condition is met. For example, during boot, if you figure there's not enough RAM, or the CPU lacks a feature that your kernel depends on, you failed to load an important system file, etc.
Implicit Invocation
Then, it is also very common to start with a single exception handler that does nothing else than calling kpanic. You set up this in the IDT for all exceptions, and as your kernel development progresses, you replace the handlers one-by-one with their final implementations. This way, exceptions that are not handled properly by your kernel will always trigger a BSOD.
Examples
Windows NT
On Windows NT, kernel panics are technically called "bug checks". Prior to Windows 8 the bug check screen displayed context info, currently it displays only a bug check code and some graphics. The bug check routine is provided by the kernel, and it uses many HAL and boot video driver functions, to reset the current display device, emulate the bios to set up a VGA mode, other services are provided by the kernel and the debugger modules, to output to the debugger, to freeze the remaining processors and mask off and disable any interrupts on the current processor, so the system would stop running.
Mac OS X
Note the complete lack of any technical information, not even an error code shown. It is worth noting that Mac OS X also has a console-only kernel panic, which looks like BSD's. (However, Mac OS X saves a memory dump to disk and starts a GDB server to allow a remote debugger to be connected on crash, so there's really no need to print any details on screen.)
FreeBSD
All about minimal required information, note the stack trace. I believe this is the optimal amount of information.
Linux
As much information as possible, important details often lost in the noise. Includes register dumps and stack trace, and requires a screen pager. Totally frightening to average users, no clear instructions for non-experts what to do.
Hobby OSes
An example of a built-in debugger on a crash screen would be OS/Z an operating system developed by one of the OSDev's forum members. For further examples, the forum topic When your OS goes crazy has many examples of funny ASCII arts.
Other
Xscreensaver's BSOD module displays mock-ups of many operating systems' kernel panics, along with a few other situations. The first half of this video shows a few of them.