カーネルパニック (kernel panic; KPとも呼ばれる^[1]) とは、コンピュータのオペレーティングシステムのカーネルが内部の致命的なエラー (英語版) を検出したときに取る安全対策である。このエラーでは、安全に回復できないか、システムを実行し続けることができず、大規模なデータ損失のリスクが大幅に高くなる。この用語は主にUnixおよびUnixライクなシステムに特有のものである。Microsoft Windowsオペレーティングシステムの場合、これに相当する用語は「ストップエラー」であり、Windowsの初期バージョンでは青背景でバグチェック画面が表示され^[2]、バグチェックコードが表示される (口語的には「死のブルースクリーン」またはBSoDとして知られている)。Xbox Oneプラットフォームでは緑背景で表示され、Windows 10プレビュービルドでも表示される^[3]。

AT&Tに由来するBSD Unixソースコードでは、panic()として知られる、panic()を処理するカーネルルーチンは、一般的にコンソールにエラーメッセージを出力し、事後デバッグのためにカーネルメモリのイメージをディスクにダンプし、その後、システムが手動で再起動されるのを待つか、自動再起動を開始するように設計されている^[4]。提供される情報は高度に技術的なものであり、システム管理者やソフトウェア開発者が問題を診断するのを支援することを目的としている。カーネルパニックは、カーネル空間の外部で発生したエラーによって引き起こされることもある。例えば、多くのUnixオペレーティングシステムは、ユーザ空間で実行されるinitプロセスが終了するとパニックになる^[5]。

Unixカーネルは、障害検出メカニズム (英語版) としてアサーションを用いて、内部の一貫性と実行時の正確性を維持する。基本的な前提は、ハードウェアとソフトウェアが正しく動作し、アサーションが失敗するとパニックが発生する、つまりシステムの全ての活動が自発的に停止することである^[6]。カーネルパニックはUnixの初期バージョンで導入され、Unixとその前身であるMulticsの設計思想の間に大きな違いを示した。Multicsの開発者のトム・ヴァン・ヴレック（英語版）は、Unixの開発者のデニス・リッチーとこの変更について議論したことを思い出している。

私はデニスに、私がMulticsで書いていたコードの半分はエラー回復コードだと言った。彼は言った「全てを省略した。エラーが発生した場合、パニックと呼ばれるルーチンがあり、それが呼ばれるとマシンがクラッシュし、『おい、再起動しろ』と廊下で大声で叫ぶ。」^[7]。

元々のpanic()関数は、UNIX第5版からVAXベースのUNIX 32Vまで基本的には変更されておらず、エラーメッセージだけを出力してそれ以外の情報を何も表示せず、システムを無限のアイドルループに落とした。 V6 UNIXのpanic()関数のソースコード:^[8]

/*
 * In case console is off,
 * panicstr contains argument to last
 * call to panic.
 */
char  *panicstr;

/*
 * Panic is called on unresolvable
 * fatal errors.
 * It syncs, prints "panic: mesg" and
 * then loops.
 */
panic(s)
char *s;
{
    panicstr = s;
    update();
    printf("panic: %s\n", s);
    for(;;)
        idle();
}

Unixのコードベースが強化されたので、panic()関数も拡張され、さまざまな形式のデバッグ情報がコンソールにダンプされる。

オペレーティングシステムのハードウェア障害やソフトウェアバグの結果として、パニックが発生する場合がある。多くの場合、オペレーティングシステムは、エラーが発生した後も動作を継続することができる。ただし、システムは不安定な状態にあり、セキュリティ侵害やデータ破損のリスクを冒すよりも、オペレーティングシステムが停止することで、さらなる損傷を防ぎ、エラーの診断を容易にし、通常は再起動する^[9]。

ソースコードからカーネルのバイナリイメージを再コンパイルした後、カーネルが正しく構成、コンパイル、またはインストールされていない場合、結果のカーネルを起動中にカーネルパニックが発生することは一般的な問題である^[10]。追加されたハードウェアやRAMの誤動作も、OSとの非互換性やデバイスドライバの欠落により、起動時に致命的なカーネルエラーの原因となる可能性がある^[11]。ルートファイルシステムを見つけることができない場合、カーネルはpanic()を実行する可能性もある^[12]。カーネルユーザ空間の初期化の最終段階では、通常、initプロセスの生成が失敗するとパニックが発生する。initプロセスが終了すると、システムが使用不能になるため、パニックが発生する可能性もある^[13]。

以下は、kernel_init()におけるLinuxカーネルの最終初期化の実装である^[14]。

static int __ref kernel_init(void *unused)
{

     ...

    /*
     * We try each of these until one succeeds.
     *
     * The Bourne shell can be used instead of init if we are
     * trying to recover a really broken machine.
     */
    if (execute_command) {
        if (!run_init_process(execute_command))
            return 0;
        pr_err("Failed to execute %s. Attempting defaults...\n",
            execute_command);
    }
    if (!run_init_process("/sbin/init") ||
      !run_init_process("/etc/init") ||
      !run_init_process("/bin/init") ||
      !run_init_process("/bin/sh"))
        return 0;

    panic("No init found. Try passing init= option to kernel. "
       "See Linux Documentation/init.txt for guidance.");
}

カーネルパニックは、他のUnixライクなシステムと同様にLinuxでも発生するが、kernel oopsとして知られている別の種類のエラー状態を生成することもある^[15]。この場合、カーネルは通常、問題のあるプロセスを終了させた後も実行を継続する。oopsにより、いくつかのサブシステムやリソースが利用できなくなる原因となるため、後で完全なカーネルパニックを引き起こす可能性がある。

Linuxでは、カーネルパニックが発生すると、キーボードのLEDが点滅して危機的な状態を視覚的に示す^[16]。

Mac OS X 10.2～10.7でカーネルパニックが発生すると、コンピュータは、システムを再起動する必要があることをユーザに通知する多言語メッセージを表示する^[17]。10.2以前は、より伝統的なUnixスタイルのパニックメッセージが表示されていたが、10.8以降では、コンピュータは自動的に再起動し、再起動後にメッセージが表示されるようになった。メッセージの形式はバージョンによって異なる^[18]。

• 
  Mac OS X 10.0から–カーネルパニック
• 
  Mac OS X10.2カーネルパニック
• 
  Mac OS X –から10.5カーネルパニック
• 
  Mac OS X10.6および10.7カーネルパニック
• 
  OS X 10.8以降のバージョンでカーネルパニックが発生したため、コンピューターを再起動した後に表示されるメッセージ

• コアダンプ
• ブルースクリーン
• 死のブルースクリーン