クラッシュ (コンピュータ)

クラッシュ（英: crash）または異常終了（いじょうしゅうりょう）とは、コンピュータの分野において、プログラムが通常とは異なる形で終了することを指す用語である。クラッシュの英語での本来の意味は「衝突、破壊、墜落」などであるが、本項では主に異常終了のケースについて記述する。

なお、ハードディスクドライブなどの補助記憶装置（ストレージ）が物理的に破損・故障して記憶内容が損なわれることを、クラッシュと呼ぶこともある。

類義語

異常終了の結果としての「ダウン」（英: down）を含め、日本語では俗に「落ちた」、「死んだ」などとも言う。

メインフレームなどでは「ABEND（アベンド、ABnormal ENDの略）」とも言う。

「crash to desktop」の略で「CTD」と呼ばれることもあり、主にコンピューターゲーム用語として使われている。

広義では「正常に動作しなくなる」ことを指し、「フリーズ」（停止、固まる）を含む意味で使われることもあるが、フリーズ状態は通例プログラムがまだ実行中であり終了しているわけではない。もしデッドロックなどに陥っているわけではなく、何らかの処理に時間がかかって応答が滞っているだけである場合、放置していればフリーズは回復する可能性もある。GUIアプリケーションのイベントループをつかさどるメインスレッド（ユーザーインターフェイススレッド）が応答不能になると、オペレーティングシステムによって応答停止を示すダイアログが表示される場合があるが、待機を続けるほかにクローズする選択肢も含まれ、クローズを選択するとアプリケーションは強制終了される。これは実質的にクラッシュに近い。

概要

プログラムの設計ミスによる不具合（バグ）の中には、プログラムの続行が許されないほど致命的な問題を引き起こすものがあり、これがクラッシュを誘発する。クラッシュの遠因になる事象は、異常値の入力、高負荷、長時間の連続稼動など様々なものがある。例えばプログラム中に異常値の入力を想定していない処理があると、異常値の入力によって整数のゼロ除算、ヌルポインタのデリファレンスやバッファオーバーラン（バッファオーバーフロー）によるアクセス違反、スタックオーバーフローなどが発生したりする。また、もし動的メモリ確保した領域を使い終わった後に解放を忘れるメモリリークの不具合があり、それが繰り返し発生すると、プログラムの長時間稼働によって使えない領域が増えていき、最終的にメモリの確保が失敗するなどの異常動作をするようになる。

理想的なコンピュータシステムでは、このような異常な状況であっても適切にハンドリングして続行するようにプログラムされなければならないが、不具合のまったく存在しないプログラムを記述するのが困難であるのと同様、あらゆる異常な状況を想定してプログラムを開発するのは困難であり、現実にクラッシュが発生するのである。

プログラミング言語によっては、ゼロ除算やアクセス違反のような異常系は一度発生するとアプリケーションコード側でのハンドリングや復帰が不可能で、即座にクラッシュを招いてしまう場合もある。例えば言語側での保護機能がほとんどないC言語やC++の場合、言語仕様上は未定義動作を引き起こすが、通例オペレーティングシステム (OS) によって異常が検知されてプログラムが強制終了される。JavaやC#の場合は例外を適切にハンドリングすることによって対処できる可能性もあるが、ごく小規模のメモリ確保ですら失敗するような状況では例外をハンドリングしても正常な続行が不可能であるケースもある。また例外が発生したとき、その例外を適切に処理する例外ハンドラーがどこにも記述されていない場合はクラッシュする。

アプリケーションソフトウェアのプログラムがクラッシュした場合は、アプリケーション（アプリ）が突然終了してしまうため、ほとんどのケースで作業中の保存していなかったデータは失われてしまう。また、画面に不自然なウィンドウやアイコンが残ったり、「保護違反」や「例外」などのシステムエラーメッセージダイアログが表示されたりするケースもある。

オペレーティングシステム (OS) やカーネル空間で動作するデバイスドライバがクラッシュした場合は、ブルースクリーンやカーネルパニックが発生したり、あるいは突然再起動がかかるなどの現象が起こる。OS上で起動中だったアプリケーションも当然すべてクラッシュしてしまう。

クラッシュ時にはこういった目に見える現象のほか、本来解放するべきメモリやリソースが解放されていない（メモリリーク、リソースリーク）、補助記憶装置上の書き込み途中だったデータが不正な状態になっている、などの問題が起きることもある。

なお近代的なマルチタスク・オペレーティングシステムでは、メモリ保護機能によって、アプリケーションプログラムがクラッシュしたとしても他のアプリケーションやOS自体に致命的な悪影響を及ぼすことのないように設計されていることがほとんどである。アプリケーションが使用していたメモリ領域やファイルも、たとえクラッシュしたとしても通常はOSによって適切に解放・クローズされる。

Microsoft WindowsやmacOS、LinuxのようなデスクトップOSと違い、iOSやAndroidのようなモバイルOSでは、アプリケーションがメモリを使いすぎて物理的な空きメモリが不足すると、ストレージへのメモリスワップはせず、OSによってプロセスが強制終了されることがある。通例、バックグラウンド状態になったアプリケーションのプロセスから優先的に強制終了されていく。ただし、たとえフォアグラウンド状態にあっても、空きメモリが不足している状態でさらにメモリを確保しようとした段階で、OSによってアプリが強制終了されてしまうこともある。いずれにせよ、この強制終了の動作はエンドユーザーの目にはクラッシュと同様に見える。

バグのようなソフトウェア的（論理的）な問題以外にも、ハードウェア的（物理的）な問題によってクラッシュが引き起こされることもある。筐体内のクーラー（冷却ファン）が故障したり、エアフローに問題があったりするなどして、CPUやGPUの冷却が不十分な場合に一定温度を超えると、オーバーヒートからハードウェアを保護するため、ファームウェアやOSの安全装置によってコンピュータが強制終了されることもある。ごくまれに、宇宙線によってメモリの電荷が破壊されてエラーが起き、システムの誤作動やクラッシュを引き起こすこともある。

クラッシュに備える技術

クラッシュリポート

クラッシュに至るバグを修正しようとする際、クラッシュ時に何が起きていたかの情報が有用である。しかしクラッシュ発生時はプログラムはすでに終了しているため、プログラム自身が情報を残すことは難しい。そこでクラッシュ時に情報を収集する仕組みをあらかじめ用意しておく例がある。この情報は特にデバッガの使えないエンドユーザー環境で発生したクラッシュの原因を特定する、「ポストモーテムデバッグ」（Post-mortem debug／プログラム検死型デバッグ）と呼ばれるデバッグ手法に役立つ。

• Windowsのブルースクリーンは、画面にエラーコードを含む情報を出力する。
  • 9x系に比べNT系は情報量が多い。
• Windowsイベントログには、アプリケーションがクラッシュしたときに、原因となった例外コードやオフセットアドレスといった情報を含むイベントが自動記録されるようになっている。
• Windowsのクラッシュダンプ、UNIX系OSのコアダンプは、クラッシュ時点のメモリ内容をファイルに書き出すことで、後の解析を可能にする。
• MozillaのBreakpadやGoogleのFirebase Crashlyticsのように、情報を開発元まで送信できるものもある。
• メインフレームの専用OSでは通常、事前の設定（SLIPなど）に従いコアダンプを出力する。
• Google Play Consoleでは、Androidアプリケーションのクラッシュや応答なし (ANR) のエラーに関する詳しい分析情報を表示することができる。

開発元にクラッシュ情報を送信するシステムは、プライバシーとセキュリティの観点から、一般的に個人が特定できない仕組みにはなっているが、使用状況と診断情報のデータを自動的に共有することに関して事前にエンドユーザーの同意が必要となっている。また、このような情報収集システムを利用したアプリケーションやサービスを欧州連合 (EU) 圏の国々で展開する場合は、EU一般データ保護規則 (GDPR) に対応しているソリューションを利用する必要がある。

自動復旧

クラッシュは避け得ないものとして、発生した際の被害を抑えたり、自動復旧させたりするための技術もある。以下はその例である。

• ジャーナリングファイルシステムは、書き込み中のクラッシュによってディスク上のデータが不整合を起こすことを防ぐ。
• 一部のサーバプログラムは、プロセスがダウンした場合に自動的に起動しなおすスクリプトを用意している。
• 高可用クラスターは、本来システムを多重化して障害に備えるためのものであるが、ハードウェア障害のみならず、プロセス監視などでソフトウェアのクラッシュにも対応する。
• データベースが備えるロールバック機能は、書き込み中のクラッシュでデータが破壊されることを防止する。
• OSのメモリ保護機能は、あるプロセスのクラッシュが他のプロセスやOS自身に波及することを防ぐ。
• Windows Vista以降に搭載されている再起動マネージャーは、同機能に対応しているアプリケーションのクラッシュ後、自動的にアプリケーションを再起動したり、編集中だったファイルの自動保存と復元をサポートしたりすることができる。

運用による緩和

根本的な解決ではないものの、運用によってクラッシュの被害を抑えたり発生率を低下させることも行われている。

• 連続稼動するサーバでは、定期リブートが効果的な場合がある。
• 作業中のデータをこまめにセーブしたり、外部ストレージにバックアップしたりすることも、個人でできる対策の一つである。

とはいえ、組み込み環境や人命にかかわるシステムなど、クラッシュが絶対に許されない厳しいケースもある。宇宙線によるクラッシュを防ぐために、エラー訂正機能を持つECCメモリが使われることもある。

脚注

関連項目

• フリーズ（ハングアップ）