A kernel panic is an operating system's response to certain types of severe computer errors. It usually displays and saves diagnostic information and then locks up the computer system or reboots. Kernel panics are typically caused by problems with malfunctioning hardware or incorrectly-written software. They are used by operating system kernels to alert users and prevent further problems once errors are detected.
Many error conditions can cause a kernel panic, including kernel code attempting to access invalid memory. Most computer hardware devices include drivers which are part of the kernel or loaded dynamically. Problems with these devices or their drivers can also trigger kernel panics. Interrupt handlers, found in many parts of the kernel, often cause panics if critical errors occur while they are running. A defective or corrupted hard disk, system file, processor or memory may also lead to a panic.
The kernel panic term originated with early UNIX® systems. Many of these displayed only a short error message and then looped endlessly, awaiting a reboot or power cycle. As UNIX® evolved, more useful debug information was generated during a panic. The Linux® operating system coined the term "Linux® kernel oops" to reflect a variety of serious errors. Some Linux® "oops" errors cause a kernel panic while others do not.
Microsoft Windows® users are usually familiar with "blue screens of death." Also known as a bug check, this is the Windows® equivalent of a kernel panic, triggered by similar conditions. Like modern UNIX® and Linux® systems, Windows® attempts to save an image of system memory to the hard disk during a bug check. In some cases, the image will be written to non-volatile memory during the panic and copied to the hard disk upon reboot. If a disk failure is the source of the panic, the system may not be able to preserve the memory image, however.
Quite often, it is possible for the operating system to continue running after a critical error occurs. The reason a kernel panic stops the system is to prevent any further corruption of software, hardware or memory contents. Halting the system in this state may preserve enough information to allow an engineer to determine the cause. The data displayed often includes specifics about the error type and the code module running at the time. It may also show all of the loaded drivers and allow a user to run a debugger in order to investigate the problem.