開けなくなった Windows レジストリ Hive ファイルを修復する
中国語や英語のコミュニティを色々と探してみましたが、驚いたことに、構造が壊れて開けなくなった（特に他のシステムのレジストリエディタからすら読み込めない）Windows レジストリの Hive ファイルを復元する方法を解説した記事が一つも見つかりませんでした。なので、ここで少しお話ししようと思います。
起因
サークルで、Windows が再起動後に起動しなくなるという修理の依頼を受けました。この PC の症状は、起動時に「スタートアップ修復で PC を修復できませんでした」と表示され、C:\Windows\System32\Logfiles\Srt\SrtTrails.txt というログファイルが提示されるというものでした。以下の画像のとおりです（日本語/中国語の画像は見つかりませんでした）。
WinRE を使ってこのファイルを確認したところ、LCU 関連のエラーが提示されていることがわかりました。しかし、当時修理を担当したサークルメンバーは LCU が何なのかを知りませんでした（私も知りませんでしたが、後で調べたら Latest Cumulative Update のことでした）。そのため、彼は次のような操作を行いました：
- WePE で起動後、内蔵のワンクリックブート修復を試みる（ESP パーティション、特に BCD の自動再構築）
- 修復に失敗。C ドライブの空き容量が全くないことに気づき、いくつかの大きなファイルを削除する
- クリーンアップ後に修復は成功したが、再起動しても問題は解決せず
- ネット上には
chkdskを実行しろとアドバイスする人までいたが（正気か？）、幸い彼は実際には実行しなかった - DISM++ での修復を試みたが、DISM++ は C ドライブ内の Windows システムを認識できなかった
- 再度 DISM++ のブート修復を使用し、成功後に再起動
再起動後、エラーメッセージは以下のようになりました（当時は写真を撮っておらず、ネット上でも中国語版の画像は見つかりませんでした。エラーコードは異なるかもしれませんが、必ず SYSTEM ファイルに問題があることが指摘されます）：
明らかに、画像はシステムのレジストリが壊れており、特に C:\Windows\SYSTEM32\config\SYSTEM というファイルが破損していることを明確に示しています。
少し基礎知識を：Windows のレジストリは複数のファイルで構成される一種のデータベースであり、これらのファイルはそれぞれ Hive と呼ばれます。プログラムが操作するもの、またはシステム内のレジストリエディタで表示されるレジストリの構造は、実際にはマッピングされた仮想的な構造です。例えば、現在のユーザー固有の設定はすべて HKEY_CURRENT_USER というルートキーの下に保存されますが、実際のデータは C:\Users\（あなたのユーザー名）\NTUSER.DAT という Hive に保存されています。システムを起動するための BCD ファイルでさえも、レジストリにマウントされています。そして、先ほどの C:\Windows\SYSTEM32\config\SYSTEM ファイルは、レジストリ内では HKEY_LOCAL_MACHINE\SYSTEM の位置にマッピングされています。
再び WePE を起動して確認すると、このファイルは存在していました。つまり、ファイル自体が破損している可能性が高いということです。残念なことに、彼の PC では復元ポイントが有効になっておらず、レジストリのバックアップもありませんでした。また、Windows 10 1803 以降では、C:\Windows\SYSTEM32\config\RegBack へのユーザー間のレジストリ Hive ファイルのバックアップが行われなくなっています。これは、Windows XP~7 時代の「前回正常起動時の構成」という起動オプションが使い物にならなくなったことを意味します。M$ はこれが Windows の使用容量を減らすためだと言っていますが、すべての Hive を合わせても数十 MB 程度であり、この程度の容量とシステム全体を再インストールするコストを天秤にかければ、全く比較にならないと言えます。そのため、この変更は理解に苦しむものです。幸い、この機能はレジストリの設定を通じて再び有効にすることができます（皮肉なことに、RegBack のバックアップを有効にするオプションは、今回壊れた HKLM\SYSTEM キーの下にあります）。
筆者の Windows To Go システムで再起動し、その中のレジストリエディタから「ハイブの読み込み」を使って破損した Hive ファイルのマウントを試みました。しかし、システムはこのファイルの読み込みを拒否しました：
バックアップファイルもなく、ネット上で他の復元方法も見つからなかったため、私たちはそのメンバーに「システムの再インストールが必要だ」と伝えるしかありませんでした。その時は遅かったため、データのバックアップだけを行い、翌日に続けることにしました。しかし、寮に戻って考えると、やはり納得がいきません。たった一つの小さなレジストリの破損のためにシステムを再インストールするのは、あまりにも割に合いません。さらに、彼の PC には多数の大型ソフトウェア（Adobe や Autodesk シリーズ）や C ドライブ内の大量の設定（各種開発ツール）があり、システムを再インストールすれば莫大な時間的コストが生じることは必至です。そのため、やはりなんとか救出を試みることにしました。
手順
前日は USB メモリを部室に置いてきてしまったため、翌日になってようやく作業を開始できました。破損した SYSTEM ファイルを自分の PC にコピーし、010 Editor で開いてざっと眺めてみました。「感覚」としては内容はすべて残っており、ファイル全体が 00 や FF になってしまうような現象は起きていなかったため、まだ救済の可能性はありました。
注意、作業を行う前に、少なくとも C ドライブ全体のイメージレベルでのフルバックアップを行うことを強くお勧めします！Ghost や DiskGenius などのツールを使用して実行できます。
もし完全な手動修復を行う場合、この時点で Windows のレジストリ Hive ファイルのフォーマットと照らし合わせて少しずつ確認する必要があるでしょう。しかし、このフォーマットは公開されておらず、有志が推測して作ったドキュメントがいくつかあるだけです。また、Hive ファイルの構造は非常に複雑で、手動で修復するのは現実的ではありません。そこで、私は次のように考えました：
- まず、Windows の Hive ファイルフォーマットを読み取れるライブラリやツールを探す必要があります。同時に、そのツールは Hive ファイルを操作するために Win32 API を使用してはならないという条件があります（先ほど WinToGo 経由で SYSTEM ファイルを開く試みが失敗したことから、Win32 API がもはやこのファイルを受け入れないことがわかっているためです）。これにより、Registry Finder や WinReg などは除外されます。
- 次に、そのライブラリやツールが Hive ファイルに書き込むこともできるのであれば、一度開いてから新しいファイルに書き出してみて、その書き出されたファイルで PC が起動できるかどうかを試すことができます。私はこのプロセスを「一度洗う / ロンダリング」と呼んでいます。
- さらに、もし Hive ファイルに書き込めるツールが見つからなかった場合、破損した Hive ファイルを開けないツールを探します。そうすれば、読み込む際にエラーが発生するため、エラーメッセージやデバッガーを利用してエラーが発生した場所を特定し、ネットで見つけられる Hive ファイルフォーマットと照らし合わせて手動で復元することができます。
幸いなことに、上記の 3 点目は必要ありませんでした。私が見つけたツール——hivex が、新しいレジストリファルを書き出すことでこの問題を修復してくれたからです。
Hivex は、libguestfs プロジェクトの下にある、Windows の Hive ファイルを操作するための C 言語ライブラリ群です。さらに良いことに、hivex には hivexml、hivexsh、hivexregedit といったいくつかの CLI ツールが用意されており、コードを書くことなく、これらのツールを直接呼び出してレジストリを処理できます。
上記のツールの中で私たちに役立つのは hivexsh、つまり「Hivex Shell」であり、コマンドライン版の regedit に相当します。
これらのツールは本来、Linux などの環境でさまざまなシステムのディスクイメージを操作するために設計されたものであり、Hivex はその付加機能の一つにすぎません。そのため、このプロジェクトには非常に UNIX らしい雰囲気が漂っています。たとえば、私より何倍も古い autoconf + make のビルドツールチェーンを使用しています。私より 2 歳年上の CMake や、私より若い Meson といったモダンなビルドツールの設定は含まれていません。そのため、Windows 上でこのツールセットをビルドするのは極めて苦痛でした。MSYS2 と 30 分ほど格闘した結果、私はきっぱりと諦め、Ubuntu の仮想マシン上で apt install を使って hivex のツール一式をインストールしました（涙）。Linux 上で Windows のシステムファイルのエラーを修復するなんて、考えると皮肉なものです。
$ sudo apt get libhivex-bin libhivex-bin-dbgsym libhivex-dev次に、破損した SYSTEM ファイルを Ubuntu にアップロードし、以下のコマンドを実行します：
$ hivexsh -uw SYSTEM # SYSTEM 是要修复的文件名，如果你的不同，就需要相应更改，u 表示允许一定程序上的结构错误（最好在不带 -u 时失败时再加上），w 表示允许写入（必须）
（此处进入了 hivexsh 的 Shell）
SYSTEM\> ls # 查看 Hive 内的内容，可以与自己电脑上的对比
SYSTEM\> commit SYSTEM_NEW # 将整个 Hive 文件写入到 SYSTEM_NEW 文件
SYSTEM\> exitそして、生成された SYSTEM_NEW ファイルを Windows システムに転送します。私の PC のレジストリエディタでこのファイルを読み込むことに成功したため、少なくともある程度は構造が修復されたことが示されました。
しかし、これは SYSTEM ファイル 1 つだけの話であり、SYSTEM.LOG1 などのログファイルもあることに注意が必要です。そのため、これらのファイルを生成する必要があります。私の方法は非常にシンプルです：生成されたファイルを自分の PC に直接読み込ませてからアンロードするだけで、これらのファイルが生成されます。
これらのファイルを故障した PC の対応するファイルに上書きし（config フォルダ内のすべての SYSTEM.xxx ファイルを削除することに注意してください）、再起動して正常にシステムに入ることができ、復元は成功しました。
ただし、もしこの手順通りにやっても成功しなかった場合、直面しているファイルの破損がより深刻であることを意味している可能性があります。その場合は、次のセクションで提供する追加のアイデアを参考にしてください。
おわりに
hivex で生成されたファイルと元の破損したファイルを 010 Editor で比較したところ、異なる箇所は 2 箇所だけでした：
ネット上で推測されている Hive ファイルの構造を調べたところ、1 つ目の箇所は Primary Sequence Number に対応しており、これが Secondary Sequence Number と同じであれば、ファイルが完全に同期されていることを示します。しかし、画像に示されている 2 つの数値（0002ADAC と 0002ADAB）は異なっていました（そのため、このように修復した後、システムに隠れた不具合が残るかどうかはわかりません）。2 つ目の箇所はファイルヘッダーの Checksum です。おそらく、これら 2 つの「小さな」問題が原因で、システムがファイルを認識しなくなったのでしょう。
実際のところ、Windows XP と Vista の時代以降、Windows のレジストリフォーマットは比較的堅牢になっており、ログファイルなどのメカニズムにより、レジストリの構造が破損することは比較的稀になっています。今回このような単純な小さな問題が Windows によって自動的に修復されず、そのまま起動を拒否してしまったことには少々驚きました。
また、もし上記の方法で問題が解決しなかった場合のために、以下の追加のアイデアを提供します：
- まずバイナリエディタでファイルを開き、すべて 0 やすべて 1 になっていないか確認します。ファイル全体がめちゃくちゃになっている場合は、もう足掻く必要はありません。
- もし hivex に
-uを付けても破損したファイルが開けない場合は、-duwを付けて大量のログを出力させ、hivex のログを分析してどこで問題が起きたのかを確認し、推測されたフォーマットドキュメントと照らし合わせて手動で修復を試みます。 - それでもダメなら、hivex 以外の Hive ファイル処理ライブラリの使用を検討してください。例えば regipy、python-registry、Registry C# ライブラリ などがあります。中でも regipy は比較的頻繁に更新されているようです。これらのツールの例外処理やログ機能を有効にして、解析プロセス中のすべてのエラーをキャプチャし、あるいはデバッガーをアタッチして問題箇所を特定した上で、手動での復元作業に入ることをお勧めします。