Kernel Panic: Difference between revisions
| [unchecked revision] | [unchecked revision] |
No edit summary |
m (→Funky side: Add link to ASCII article) |
||
| (5 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
A '''kernel panic''' is an unrecoverable system error. |
|||
Unrecoverable system errors are called kernel panics. |
|||
== Overview == |
== Overview == |
||
[[File:bsod_xp.png|200px|thumb|Windows XP]] |
[[File:bsod_xp.png|200px|thumb|Windows XP]] |
||
[[File:bsod_mac.jpg|200px|thumb| |
[[File:bsod_mac.jpg|200px|thumb|Mac OS X]] |
||
[[File:bsod_bsd.jpg|200px|thumb|FreeBSD]] |
[[File:bsod_bsd.jpg|200px|thumb|FreeBSD]] |
||
[[File:bsod_linux.jpg|200px|thumb|Linux]] |
[[File:bsod_linux.jpg|200px|thumb|Linux]] |
||
| Line 10: | Line 10: | ||
=== History === |
=== 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". |
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 |
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 === |
=== 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. |
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. |
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 system crash happens. For example Amiga could be debugged remotely using serial connection, and some modern systems start |
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 |
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. |
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. |
||
| Line 28: | Line 28: | ||
=== Funky side === |
=== Funky side === |
||
Because 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". |
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 |
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. |
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 == |
== 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", but you can give any name |
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 |
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. |
For an example, an implementation could load a self-contained <tt>kpanic()</tt> 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: |
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 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 |
- 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. |
- 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. |
- 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. |
- 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. |
- load this module as soon as possible, allowing the kernel to panic during boot if needed. |
||
=== Explicit Invocation === |
=== Explicit Invocation === |
||
You can call this kpanic from your kernel when a specific error condition 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 load an important system file etc. |
You can call this <tt>kpanic</tt> 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 === |
=== 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. |
Then, it is also very common to start with a single exception handler that does nothing else than calling <tt>kpanic</tt>. 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 == |
== Examples == |
||
=== Windows NT === |
=== 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. |
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 |
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 === |
=== FreeBSD === |
||
All about minimal required information, note the stack trace. I believe this is optimal amount of information. |
All about minimal required information, note the stack trace. I believe this is the optimal amount of information. |
||
=== Linux === |
=== Linux === |
||
| Line 75: | Line 75: | ||
=== Hobby OSes === |
=== 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 [https://forum.osdev.org/viewtopic.php?f=1&t=18924 When your OS goes crazy] has many examples of funny ASCII arts. |
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 [https://forum.osdev.org/viewtopic.php?f=1&t=18924 When your OS goes crazy] has many examples of funny ASCII arts. |
||
=== Other === |
|||
[https://www.jwz.org/xscreensaver/ Xscreensaver's] BSOD module displays mock-ups of many operating systems' kernel panics, along with a few other situations. The first half of [https://www.youtube.com/watch?v=YIqbMCfR3r0 this video] shows a few of them. |
|||
== See Also == |
== See Also == |
||
* [[wikipedia:Crash (computing)|Wikipedia on Crash]] |
|||
* [https://en.wikipedia.org/wiki/Guru_Meditation Wikipedia on Guru Meditation] |
|||
* [ |
* [[wikipedia:Guru Meditation|Wikipedia on Guru Meditation]] |
||
[[Category:OS Development]] |
[[Category:OS Development]] |
||
Latest revision as of 08:03, 13 December 2023
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.