WindowsServer2012R2で発生するBAD_SYSTEM_CONFIG_INFOを安全に修復する完全ガイド

WindowsServer2012R2で発生するBAD_SYSTEM_CONFIG_INFOを安全に修復する完全ガイド

Windows Server 2012 R2を起動した直後、突如として画面に表示されるブルースクリーン（BSoD）と「BAD_SYSTEM_CONFIG_INFO」というエラーコード。この深刻なシステム障害は、企業の業務停止やデータ損失に直結しかねない極めて重大な局面です。多くのフォーラムでは「OSの再インストールしかない」といった極端な解決策が提示されがちですが、安易な初期化はサーバー内の重要な業務データや設定をすべて失うリスクを伴います。本記事では、このエラーが発生する根本的な原因を独自に徹底分析し、データを1バイトも失うことなくシステムを安全に稼働状態へと復旧させるための具体的かつ実戦的なステップを、世界一詳しく解説します。

BAD_SYSTEM_CONFIG_INFOがWindows Serverで発生する根本原因

レジストリファイルの破損とハイブの不整合

BAD_SYSTEM_CONFIG_INFO（停止コード: 0x00000074）の最大の原因は、Windowsのシステム設定を司る「レジストリ」の破損です。特に、システムの起動に不可欠な「SYSTEM」や「SOFTWARE」といったレジストリハイブ（ファイル）が、予期せぬシャットダウン、停電、またはハードウェアの瞬間的な瞬低によって正常に書き込まれなかった場合、OSは起動プロセスを継続できなくなります。サーバーOSはクライアントOSに比べて常に多くのバックグラウンド処理を実行しているため、書き込み中の電源断によるレジストリ破損リスクが構造的に高いという特徴があります。

起動構成データ（BCD）のエラーと設定ミス

もう一つの主要な原因は、ブートローダーが参照する起動構成データ（BCD: Boot Configuration Data）の破損、または記述ミスです。システムアップデートの失敗や、不適切なディスクパーティションの変更、あるいはサードパーティ製のバックアップソフトがブートセクタを誤って書き換えた場合、BCD内に存在しないドライブを指すタイポ（記述誤り）や、不正なメモリ構成（numprocやtruncatememoryの誤設定）が生じることがあります。これにより、OSは起動時に必要なハードウェア情報を正確に読み取れず、自らを保護するためにシステムを強制停止させます。

想定されるトラブルと対策：修復中のセカンダリ障害

この段階で最も恐れるべきトラブルは、焦って「ドライブのフォーマット（初期化）」や「安易なOSの上書きインストール」を実行してしまうことです。これにより、破損しているのが一部の起動ファイルだけだったにもかかわらず、サーバー内の全共有データやActive Directoryのデータベースまで完全に消失する事態に発展します。対策として、システム修復作業に移行する前には、必ず独立した環境でデータを退避させる「データ最優先の防衛策」を徹底しなければなりません。

サーバー復旧へ向けた3つの事前準備とデータ保護策

1. 適合するWindows Serverインストールメディアの用意

修復作業を開始するには、対象のサーバーに導入されているOSと完全に一致する「Windows Server 2012 R2」のインストールメディア（USBインストーラーまたはDVD）が必須です。バージョンやエディション（Standard、Datacenterなど）が異なると、修復用のコマンドが正しくシステムを認識しない場合があります。メディアを作成する際は、信頼できるクリーンな端末を使用し、書き込みエラーのない状態のブートスティックを準備してください。

2. Windows PE環境を活用したデータの超先行バックアップ

システムが起動しない状態でも、インストールメディアから起動して「Windows PE（Preinstallation Environment）」の環境を立ち上げることで、内部のデータを救出できます。コマンドプロンプトを呼び出し、外付けHDDやネットワーク上の共有ストレージに対して、最重要データ（データベースファイルや設定構成シートなど）を事前にコピーします。万が一、その後の修復コマンドによってシステムが完全にクラッシュした場合でも、データさえ無事であればサーバーの再構築によるリカバリが可能になります。

3. ハードウェアの物理的状態の確認

レジストリ破損の裏には、ストレージ（HDD/SSD）の物理的な不良セクタの発生や、メモリの不具合が隠れているケースが多々あります。修復コマンドを実行する前に、サーバーの構成パーツに異常がないか、マザーボードの診断機能（インテリジェント・プラットフォーム・マネジメント・インターフェース：IPMIなど）を利用してハードウェアステータスを確認しておきます。ハードウェア自体が壊れている場合、いくらソフトウェア側を修復してもエラーはループし続けます。

BAD_SYSTEM_CONFIG_INFOを解消する具体的行動手順

ここからは、実際にサーバーを復旧させるための詳細な手順をステップバイステップで解説します。指示通りに正確にコマンドを入力してください。

ステップ1：回復環境（コマンドプロンプト）の起動

1. 作成したWindows Server 2012 R2の起動用USBスティックをサーバーに挿入し、電源を投入します。

2. 画面に「Press any key to boot from CD or DVD」と表示されたら、任意のキーを押してメディアから起動します。

3. 言語とキーボードレイアウトの選択画面（最初の画面）が表示されたら、「次へ」をクリックします。

4. 次の画面の左下に表示される「コンピューターを修復する（Repair Your Computer）」を選択します。

5. オプションの選択画面から「トラブルシューティング」をクリックし、続いて「詳細オプション」を開きます。

6. メニュー内から「コマンドプロンプト」をクリックして起動します。

ステップ2：システムファイルチェッカー（SFC）とDISMによる整合性修復

レジストリを操作する前に、まずはOSの基盤となるシステムファイル自体を修復します。通常のコマンドとは異なり、回復環境から実行する場合はオフライン用のパス指定が必要です。

1. コマンドプロンプトに以下のコマンドを入力し、Windowsがインストールされているドライブレター（通常はCまたはD）を確認します。

Plaintext

 

dir c:

（Windowsフォルダが存在するドライブが対象となります。ここでは対象を「Cドライブ」と仮定します）

2. 次のコマンドを入力して、破損したシステムファイルを自動検出・修復します。

Plaintext

 

sfc /scannow /offbootdir=c:\ /offwindir=c:\windows

3. スキャンが完了し、破損ファイルの修復が行われた旨が表示されたら、続けてOSのコンポーネントイメージを修復するために以下のコマンドを実行します。

Plaintext

 

dism /image:c:\ /cleanup-image /restorehealth

ステップ3：レジストリバックアップ（RegBack）からの個別復旧

SFCで解決しない場合、レジストリの「SYSTEM」ハイブが物理的に壊れています。Windows Server 2012 R2には、定期的に自動保存されているレジストリのバックアップ（RegBack）が存在するため、これを手動で現在のシステムに上書きすることで、正常だった時点の状態へ巻き戻します。

1. 現在の破損しているレジストリが存在するディレクトリへ移動します。

Plaintext

 

cd c:\windows\system32\config

2. 万が一に備え、現在のレジストリファイルを退避させるためのバックアップフォルダを作成します。

Plaintext

 

mkdir registry_backup

3. 既存の主要レジストリファイルを、作成したフォルダへコピーします。

Plaintext

 

copy *.* registry_backup

4. 自動バックアップが保存されている「RegBack」ディレクトリへ移動します。

Plaintext

 

cd RegBack

5. このディレクトリ内に存在する「DEFAULT」「SAM」「SECURITY」「SOFTWARE」「SYSTEM」のファイルサイズを確認します（すべて0バイトでなければ利用可能です）。確認後、以下のコマンドで現在の設定に上書きコピーします。

Plaintext

 

copy *.* ..

（上書きの確認を求められた場合は「A」（すべて上書き）を入力します）

ステップ4：ブート構成データ（BCD）の再構築とタイポ修正

レジストリの復旧と同時に、起動エラーを誘発しているブート設定のクリーニングを行います。

1. コマンドプロンプトに以下のコマンドを順に入力し、マスターブートレコードとブートセクタを修復します。

Plaintext

 

bootrec /fixmbr
bootrec /fixboot

2. 続いて、BCDの中に間違った設定（numprocなどのバグの原因となるフラグ）が混入していないかを確認し、初期化・再構築を行います。

Plaintext

 

bootrec /rebuildbcd

3. システムに存在するWindowsのインストール環境が検出されたら、「Y」を入力して起動一覧に追加します。

4. コマンドプロンプトを閉じ、サーバーを再起動して正常にOSが立ち上がるか確認します。

各復旧アプローチの特徴とリスク管理一覧

システム修復におけるアプローチは、選択を誤ると致命的なデータ消失を招きます。以下に、本記事で推奨する手順と、避けるべきNG対応の比較データをまとめました。自身の状況に合わせて最適な判断を行ってください。

復旧アプローチ	データの安全性	作業難易度	復旧までの想定時間	メリット・デメリット
データ先出＋RegBack修復 （本記事推奨）	極めて高い （100%データを保護）	中〜高 （CUI操作が必要）	30分 〜 1時間	システム設定を維持したまま最小のダウンタイムで完全復旧が可能。
SFC / DISMオフライン実行	高い （データ変更なし）	中 （コマンド入力のみ）	15分 〜 30分	安全性が高いが、レジストリ自体の深い物理的破損には効果が薄い場合がある。
システムの復元（Restore）	中 （直近のデータ消失リスク）	低 （GUI操作）	20分 〜 45分	簡単だが、サーバー環境では復元ポイントが未作成、または無効化されていることが多い。
OSのクリーンインストール	最悪 （完全消失のリスク）	低 （ウィザードに従う）	2時間 〜 数日 （再構築含む）	確実に起動はするが、これまでの設定、アプリケーション、全データが消滅する最終手段。

 

サーバー復旧後に即座に実施すべき3つの再発防止策

1. 不正なブート構成フラグの完全排除

無事にサーバーが起動した後は、再び起動構成データに不整合が生じないよう、稼働中のOS内から不要な制限フラグを削除します。管理者権限でコマンドプロンプトを開き、以下の2つのコマンドを実行してください。

Plaintext

 

bcdedit /deletevalue {default} numproc
bcdedit /deletevalue {default} truncatememory

これにより、過去に誤って設定された可能性のあるCPUコア数やメモリ容量の制限値がクリアされ、OSがハードウェアのポテンシャルを100%正常に認識して起動するようになります。

2. ディスク書き込みキャッシュと電源管理の最適化

予期せぬシャットダウンによるレジストリ破損を二度と起こさないために、サーバーの電源環境を強化します。無停電電源装置（UPS）を確実に配備し、停電時には安全に自動シャットダウンが走るスクリプトを組んでください。また、デバイスマネージャーからストレージのプロパティを開き、「高パフォーマンス」を維持しつつも、予期せぬ切断に耐えられるようキャッシュポリシーが適切に運用されているかを再評価します。

3. VSS（ボリュームシャドウコピー）と完全イメージバックアップの自動化

手動でのレジストリ復旧は強力な手段ですが、日頃からの自動バックアップに勝るものはありません。Windows Serverバックアップ機能を有効化し、システム状態（System State）を含むベアメタル回復用のフルバックアップを、毎日深夜などの低負荷時間帯にスケジュール実行する仕組みを構築してください。これにより、将来的に同様のBSoDが発生した場合でも、数クリックで確実に前日の正常な状態へとシステム全体をロールバックすることが可能になります。