マシンチェック例外(MCE )とは、コンピュータのハードウェアに問題が検出された際に発生するコンピュータエラーの一種です。市販されているほとんどのパーソナルコンピュータでは、MCEはハードウェアの不具合または設定ミスを示します。
MCE(マルチコードエラー)の性質と原因は、システムのアーキテクチャと世代によって異なります。一部の設計では、MCEは常に回復不能なエラーであり、マシンを停止させ、再起動が必要になります。他のアーキテクチャでは、 ECCメモリによって訂正されるシングルビットエラーなど、MCEが致命的ではない場合もあります。PowerPCなどの一部のアーキテクチャでは、無効なメモリアクセスなど、特定のソフトウェアバグがMCEを引き起こす可能性があります。x86などの他のアーキテクチャでは、 MCEは通常、ハードウェアのみに起因します。
報告
IBMメインフレームオペレーティングシステム
IBM System/360 オペレーティング システム( OS/360 ) は、SYS1.LOGREC と呼ばれるデータセットに入出力エラーを記録します。それ以来、IBM は、インストール時に名前を選択できる後継バージョンや、OS/360 から派生していないオペレーティング システムに対して、エラー記録データセット( ERDS ) という用語を作り出しました。 [ 1 ]
OS/360
OS/360では、インストール時にマシンチェックの処理に関する複数のサポートレベルを選択できます。最も高度なマシンチェックハンドラ(MCH)は、障害データをSYS1.LOGRECに記録し、リカバリを試みます。インストール時には、環境レコード編集および印刷プログラム(EREP)サービス補助ツール、またはスタンドアロン版のSEREPを使用して、これらのデータを印刷できます。MCHは、 SYS1.ASRLIBから新しいコピーを読み込むことで、リフレッシュ可能な核制御セクションのメモリ障害を処理でき、SYS1.SVCLIBからSVCモジュールの新しいコピーを読み込むことで、SVCトランジェント領域のメモリエラーを処理できます。
z/OS
z/OS では、インストール時に ERDS を使用するか、エラー データを保持する az/OS システム ロガー ログ ストリーム[ 2 ]を定義できます。OS/360 と同様に、インストールでは EREP を使用してこれらのデータを出力します。SEREP は使用できなくなりました。MCH はオプションではなくなり、OS/360 MCH よりもはるかに多くの障害モードを処理します。ページング可能なリンク パック領域 (PLPA) 内の回復不能なメモリの場合、z/OS はページ フレームを使用不可としてマークし、ページをページ アウトとしてマークします。次の参照ではページ フォルトが発生し、別のページ フレームが割り当てられます。
マイクロソフトWindows
Microsoft Windowsプラットフォームでは、回復不能な MCE が発生した場合、システムは BugCheck (STOP エラーまたはブルースクリーンとも呼ばれる) を生成します。
より新しいバージョンの Windows は、 Windows ハードウェア エラー アーキテクチャ(WHEA) を使用し、STOP コード 0x124、WHEA_UNCORRECTABLE_ERROR を生成します。4 つのパラメータ (括弧内) は変化しますが、MCE の場合は最初のパラメータは常に 0x0 です。[ 3 ]例:
停止: 0x00000124 (0x0000000000000000, 0x0000000000000000, 0x0000000000000000, 0x0000000000000000)
古いバージョンのWindowsでは、マシンチェックアーキテクチャが使用され、STOPコードは0x9C、MACHINE_CHECK_EXCEPTIONとなります。[ 4 ]例:
停止: 0x0000009C (0x00000030, 0x00000002, 0x00000001, 0x80003CBA)
Linux
Linuxでは、カーネルはMCE に関するメッセージをカーネルメッセージログとシステムコンソールに書き込みます。MCE が致命的でない場合、通常はシステムログやsystemd ジャーナルにもコピーされます。一部のシステムでは、ECC やその他の訂正可能なエラーが MCE 機能を通じて報告される場合があります。[ 5 ]
例:
CPU 0: マシンチェック例外: 0000000000000004 バンク2:f200200000000863 カーネルパニック: CPUコンテキストが破損しています
問題の種類
MCEを引き起こす主なハードウェアの問題には、以下のようなものがあります。
考えられる原因
マシンチェック例外は通常、ソフトウェアの問題ではなくハードウェアの問題です。多くの場合、オーバークロックや過熱が原因です。場合によっては、CPUは永久的な損傷を避けるために、熱制限を超えると自動的にシャットダウンします。しかし、メモリやI/Oデバイスなどの他のコンポーネントの故障によって引き起こされるバスエラーによっても発生する可能性があります。考えられる原因は次のとおりです。
- CPUヒートシンクやケースファン(またはフィルター)に埃が詰まっていたり、緩んでいたりするため、CPUの冷却性能が低下します。
- CPUが安定して動作する最高クロック周波数を超えてオーバークロックすること。
- マザーボードの故障。
- プロセッサの故障です。
- 記憶力の低下。
- マザーボードまたは専用カード上のI/Oコントローラに不具合が発生しています。
- 入出力デバイスの故障。
- 電源供給が不十分、または故障している。
- 環境問題[ 6 ]
- ソフトウェアに起因するハードウェアエラー
冷却の問題は、通常、点検すればすぐにわかります。マザーボードやプロセッサの故障は、正常な部品と交換することで特定できます。メモリは、memtest86などの診断ツールを起動してチェックできます。重要でないI/Oデバイスやコントローラの故障は、可能であればそれらを取り外すか、デバイスを無効にして問題が解消されるかどうかを確認することで特定できます。故障がOS起動後すぐに発生する場合、または全く発生しないか、数日間発生しない場合は、電源の問題が考えられます。電源の問題の場合、OSが外部デバイスを起動して使用を開始する際の電力需要のピーク時に故障が発生することがよくあります。
MCEの解読
IA-32 および Intel 64 プロセッサについては、Intel 64 および IA-32 アーキテクチャ ソフトウェア開発者マニュアル[ 7 ]第 15 章 (マシンチェック アーキテクチャ) または Microsoft KB の Windows 例外に関する記事[ 8 ]を参照してください。
IntelおよびAMD MCEをデコードするプログラム
- rasdaemon [ 9 ]は、 Linux用のRAS (信頼性、可用性、保守性) ロギング ツールです。EDAC トレース イベントを使用してメモリ エラーを記録します。EDACは、i386 および x86_64 アーキテクチャのほとんどのチップセットのメモリ コントローラからの ECC エラーの検出を処理する Linux カーネル サブシステムです。arm などの他のアーキテクチャ用の EDAC ドライバも存在します。mcelog は 2017 年以降非推奨となっているため、Linux システムで MCE 情報を収集するには rasdaemon を使用することをお勧めします。[ 10 ] [ 11 ] [ 12 ] [ 13 ]
- mcelog [ 14 ]は、x86 プロセッサの MCE を処理する Andi Kleen による Linux デーモンです。mcelog はマシン チェックをデコードすることもできます。mcelog は 2017 年現在、機能的に廃止されていると考えられています。[ 12 ] [ 13 ] Linux システムにおける mcelog の代替は rasdaemon です。[ 10 ] [ 11 ]
- parsemce [ 15 ]は、 AMD K7プロセッサからの MCE をデコードするための Dave Jones による Linux プログラムです。
- mced [ 16 ] (mcedaemon) は、カーネルから MCE を収集し、関心のあるアプリケーションに通知する Tim Hockin による Linux プログラムです。MCE データを解釈しようとはせず、単に他のプログラムに通知するだけであることに注意してください。
- mcatは、 AMD K8、ファミリー0x10および0x11プロセッサからのMCEをデコードするための、AMD製のWindowsコマンドラインプログラムです。
参考文献
- ↑ 「第 1 章 EREP の紹介」(PDF) .環境記録編集および印刷プログラム (EREP) 3.5 - ユーザー ガイド(PDF) . IBM . 2021 年 9 月 30 日。p. 1. GC35-0151-50 . 2023 年2 月 20 日取得.
- ↑システム プログラマーズ ガイド: z/OS システム ロガー(PDF)。レッドブック (第 2版)。IBM 。2007年 7 月。SG24-6898-01 。2023年2 月 20 日取得。
- ↑ "バグチェック 0x124: WHEA_UNCORRECTABLE_ERROR" . Microsoft. 2022-11-03 . 2022-12-11に取得.
- ↑ 「バグチェック 0x9C: MACHINE_CHECK_EXCEPTION」。Microsoft。2021年12月14日。 2022年12月11日取得。
- ↑ 「mcelog が SLES11 SP3 上の AMD プロセッサ ファミリー 16 以上で動作しない」。SuSE。2022-09-27。2022-12-11に取得。
- ↑ 「警告」(PDF) . z/Architecture Principles of Operation (PDF) (第15版). IBM . 2025年4月. pp. 11–17 . SA22-7832-14 . 2025年7月3日取得.
- ↑ 「マシンチェックアーキテクチャ」。Intel® 64およびIA-32アーキテクチャソフトウェア開発者マニュアル第3B巻:システムプログラミングガイド、パート2。インテルコーポレーション。2018年11月。
- ↑ 「Windows XPで発生する可能性のある停止エラーメッセージ: "0x0000009C (0x00000004, 0x00000000, 0xb2000000, 0x00020151)"" . MSDN . 2015-12-07 . 2017-07-13に取得.
- ↑ Mauro Carvalho Chehab (mchehab) (2023-02-20). "rasdaemon は RAS (信頼性、可用性、保守性) ログツールです" . github.com . 2023-02-20に取得。
- 1 2 "マシンチェック例外" . wiki.archlinux.org . 2021-05-08 . 2023-02-21に取得.
- 1 2 "ECC RAM" . wiki.gentoo.org . 2022-12-30 . 2023-02-21に取得.
- 1 2 "x86/mce: /dev/mcelog ドライバを分離して非推奨にする" . git.kernel.org . 2017-03-28 . 2023-02-21に取得.
- 1 2 "x86/mce: /dev/mcelog ドライバを分離して非推奨にする" . github.com/torvalds/linux/ . 2017-03-28 . 2023-02-21に取得.
- ↑ "mcelog: x86 Linux 用の高度なハードウェア エラー処理" . 2015-04-20 . 2017-07-13に取得.
- ↑ "parsemce: Linux マシンチェック例外ハンドラパーサー" . 2003-07-22 . 2017-07-13に取得.
- ↑ GitHub上のmcedaemon
外部リンク
- mcelog: x86 Linux 向けの高度なハードウェア エラー処理
- parsemce: Linux マシン チェック例外ハンドラー パーサー