壊れたラップトップの復旧記録:Windows 10 が起動しない問題の解決法

さて、数日前に、調子の悪くなったラップトップと、8つのOSを切り替えて起動できるWindowsとLinuxのマルチブート環境からKDE neonを復旧させた話をお伝えしました。結果として、いくつかのディストリビューションが起動しなかった原因は、存在しないパーティションをマウントするよう設定されていたことにありました。これは、新しいLinuxシステムがデバイスを識別する際に、単純な数字ではなく、人間には読めない無意味なUUID文字列を使用するという、あまり優秀とは言えない方式を採用しているために起こったものです。

今回は、Windows 10側も修正する必要がありました。こちらの症状はやや似ていて、Windows 10は起動を開始するものの、「PCを診断しています」というメッセージとともに自動修復が走り、そして予想どおり、自動修復は失敗するというものでした。前回の記事で、Windows 10のパーティションは健全であり、データもすべて残っていることは確認済みだったため、リセットなどの手段は取りたくありませんでした。この厄介な問題をどのようにスマートに解決したのか、順を追ってご紹介します。

問題の詳細

淡い青色のWindows 10リカバリコンソール画面には、次のように表示されていました。

自動修復ではPCを修復できませんでした。
[詳細オプション]を押して他の修復オプションを試すか、[シャットダウン]を押してPCの電源を切ってください。
ログファイル:C:\Recovery\WindowsRE\Winre.wim\System32\Logfiles\Srt\SrtTrail.txt

技術者としての流儀に従い、最善の策は「詳細オプション」からコマンドプロンプトを起動し、ログファイルへ移動して内容を確認することだと判断しました。ところが、このファイルは存在していなかったのです。この点については後ほど触れます。

この時点で、以前に行ったシステムイメージからの復元テストが、問題の一因、あるいは全部の原因になっている可能性を考えました。となれば、Windows 10のブートローダーの修復が必要かもしれません。Linux側のブートローダーで起動順序を制御していたため疑問は残りましたが、まずは明白な原因を排除するため、定番のブートローダー修復コマンドを試すことにしました。

bootrec.exe /rebuildbcd
bootrec.exe /fixmbr
bootrec.exe /fixboot

しかし、すぐに問題にぶつかりました。Windows 10のUSBインストールメディアからこれらのコマンドを実行すると、何も検出されません。これにも理由があるのですが、それは後述します。一方、リカバリコンソールから実行すると、1件は検出されるものの、参照先がC:\ドライブではなくD:\ドライブになっており、実際にエントリを追加しようとすると、コマンドは処理を完了できないと訴えます。

指定されたパスが見つかりません。

さらに、最後のコマンドでは次のエラーが発生しました。

アクセスが拒否されました。

ログファイルが本来C:\直下にあるはずなのに存在せず、bootrec.exeがD:\配下にOSを検出したという事実。この2点から、ドライブレターが正しく割り当てられておらず、それを修正する必要があると推測しました。それでは、解決策に進みましょう。

解決策 1:ドライブレターの修正

まずcmdからdiskpartツールを起動しました。通常Windowsで使うディスクの管理はGUIですが、ここではコマンドライン版のコマンドを操作することになります。何をすればよいか分からない場合は、「?」と入力すれば利用可能なオプションやフラグの一覧を確認できます。まずは、ボリュームへのドライブレター割り当て状況をチェックしましょう。

diskpart
list volumes

私の環境では、C:\ドライブが誤ったボリュームに割り当てられていることが分かりました。そこで修正を行います。もしC:というレターが既に使用されている場合は、2段階の作業が必要です。まず該当ドライブを空いている別のレターに割り当て直し、その後で正しいボリュームにC:を割り当てます。以下はその例です(実際のボリューム番号は環境ごとに異なるため、あくまで参考としてください)。

select volume 2
assign letter=(C以外の空いているレター):

select volume 5
assign letter=C:

この修正後にbootrec.exeを再実行すると、状況は進展しました。しかし、それでもシステムは起動しません。

解決策 2:EFIパーティションのブートイメージ再構築

この時点で、問題はブートローダーではないと確信しました。そこで、ブートプロセスの次の段階、すなわちEFIパーティション上に配置されているブートイメージに目を向けます。何らかの理由でこのファイルが破損しており、再構築が必要な状態なのかもしれません。

リカバリコンソールを起動し、再びdiskpartによる作業を行います。今度の手順は2段階です。第一に、正しいボリュームがC:\にマッピングされていることを確認すること。第二に、操作対象がEFIパーティションであることを確実にすることです。ドライブレターには細心の注意を払ってください。誤操作が心配であれば、対象ボリュームを選択して新しいレターを割り当ててから、ブートイメージの再構築に進むと安全です。レターが既に正しければ、この作業は省略できます。

diskpart
list volumes
# C: に対応するパーティションを選択
select volume X
assign letter=C:
# EFIパーティションを選択(FAT32形式、ブートフラグ付き、多くの場合非表示)
select volume Y
assign letter=F:
exit

EFIパーティションにはFというレターを割り当てました。ここは任意のレターで構いません。続いて、ブートイメージの修復ステップです。

bcdboot.exe C:\Windows /s F: /f UEFI

ここで何を行っているのか、bcdbootの各要素を分解してみましょう。

• ソース(C:\Windows):BCDファイルをもとにシステムパーティションを初期化します。
• /s:システム(EFI)パーティションのドライブレターを指定します。
• /f:ファームウェアの種類を指定します。

/sと/fはどちらも省略可能なオプションです。詳細についてはマイクロソフトのテクニカルリファレンスを参照してください。

このステップが完了したところで再起動すると、Windows 10は問題なく起動し、中身はすべて元のまま残っていました。その他のLinuxディストリビューションもすべて正常に動作し、GRUB2は一切手を加えておらず、データ損失もゼロです。

まとめ

この一連の作業はかなり苛立たしいものでしたが、同時にどこか楽しめる要素もありました。深い技術的な領域に入ると、Windowsは驚くほどLinuxとよく似た挙動を示します。そして、システム起動エラーへの対応に関しては、同じように曖昧で、回復力に欠けています。なぜ自動修復は、私が手動で行った程度の処理すら実行できなかったのか不思議でなりません。私が踏んだ手順には、特別なことも魔法のようなことも何ひとつ含まれていないのですから。さらに、ログへのアクセスも容易ではありません。最初のエラー画面で、その場でユーザーがログを読めるようにしておけばよいのに、と思うわけです。

もう一つの問題は、システムが期待する状態(たとえばドライブレター)との間に食い違いが生じると、本質から逸れた二次的なトラブルが次々と発生し、思考を妨げられることです。解決策自体はそれほど難しくありませんが、無意味な切り分け作業に時間を浪費してしまいます。それが現代のソフトウェアというものなのでしょう。とはいえ、マルチブート環境でWindows 10の起動に問題が発生した際に、何を試せるのかを少しでも明確にできたなら幸いです。データが無事であることを確認できたら、シンプルな対処から始めて、ブートシーケンスを一段階ずつ丁寧にたどっていくのが鉄則です。思想の面でもLinuxと同じで、将来は決してバラ色ではない。だからこそ、すべてが抽象的な悪夢と化してしまう前に、今あるわずかな技術的自由を存分に楽しんでおきましょう。

それでは、また。