Windows システムドライブをクローンして OS が起動しない場合(エラーコード:0xc0000225)の対応方法

Page content

ストレージの入れ替えで、 Windows システムドライブをクローンする機会はそこそこある。

通常は、 dd コマンドなどのセクターレベルでのコピーで問題なくクローンできるが、 場合によってはクローンしたドライブで起動できないことがある。

今回は、そんな状況になったクローン後のドライブの復旧方法についてのネタである。

なお、低水準にストレージにアクセスすることになるので、 少しの間違いで致命的な状態になる可能性になる。 事前にバックアップを作成 することを強くオススメする。

また、以下の手順に沿って作業した際に発生するいかなる損害も、保証いたしません。 各自の自己責任でお願いします。

ストレージの容量が異なる

今回はクローン元のドライブが 2TB で、クローン先のドライブが 1TB という構成だった。

ドライブをクローンする多くの場合、 「クローン元のサイズ」 <= 「クローン先のサイズ」 で行なうのが原則だと思うが、 今回はその逆だった。

どうしてこの構成にしたかというと、 このクローン元の 2TB のドライブは、 1TB と 1TB のパーティションに分かれていて、 それぞれシステムとデータになっている。 なお、実際はもっと windows 管理の細かいパーティションに分かれているが、 大きいサイズのパーティションはこの2つだ。

そして、どうしてこんなパーティション構成になっているかというと、 元々は 1TB のドライブがあって、それを 2TB ドライブにクローンし、 空いてる 1TB の領域にデータ用のパーティションを作成していたためだ。

そんな訳で、後方の 1TB のデータパーティション以外の前方の領域をコピーすれば、 問題なく起動する想定だった。

そのときのコマンドは大体以下のような感じ。 (あくまでイメージ)

$ sudo dd if=/dev/クローン元 of=/dev/クローン先 bs=100M count=10000 status=progress

BIOS に起動ドライブとして認識されない

上記のようにコピーしたドライブを使って起動してみたが、起動しない。 そもそも、 bios に起動ドライブとして認識されない。

何故か?

コピーしたドライブに対して以下を実行しパーティションの状態を確認。

$ sudo fdisk -l /dev/クローンしたドライブ

しかし、想定とは違うパーティション情報が表示された。

この現象が起る原因として考えられるのは、次の2つ。

  • そもそも GPT は、ストレージの LBA 先頭の領域だけでなく、 末尾の領域にバックアップがある。今回は、末尾の領域をコピーしていない。
  • 今回コピーしたのは元々 2TB のドライブで、 後方の 1 TB のデータ用パーティションの情報も含んでいる。

つまり、先頭の領域の GPT のパーティション情報を見ると、 ドライブのサイズを越えたパーティションが含まれているため、 プライマリ GPT 情報が壊れていると認識し、 ドライブ末尾のバックアップ GPT を見てみるが、そこにはマトモな GPT情報がない。 そんな状態なので、 fdisk がパーティション情報を表示できない。

そこで、 gdisk で不要なデータパーティションの情報を削除する。

$ sudo gdisk /dev/クローンしたドライブ
p ※ データパーティションの番号を確認
d
データパーティションの番号
p ※ データパーティションが消えていることを確認
w

再度 fdisk を実行し、正常に反映されていることを確認する。

$ sudo fdisk -l /dev/クローンしたドライブ

これで、起動すると BIOS に起動ディスクとして認識され、OS も起動する。

存在しないパーティション情報を含んでクローンしていたことは認識していたが、 「起動確認した後で消せば良いだろう」と思っていた。 しかし、パーティション情報に不整合を解決してからでないと、起動しないらしい。

ドライブをオンラインにしてはならない

クローン元のドライブとクローン後のドライブを両方接続した状態で、 クローン元のドライブから windows を起動した。

ここで、エクスプローラを見ると、クローン後のドライブが認識されていない状態だったので、 「コンピュータの管理」から「ディスクの管理」を開いてクローン後のドライブの状態を 確認すると、「オフライン」になっていることが判った。

『「オンライン」にすれば認識されるだろう』と思って「オンライン」すると、 ドライブが認識されてエクスプローラに表示された。

そして、今度はクローン後のドライブから起動すると、OS 起動でエラーする。

このときのエラーコードは、 0xc0000225 。

ついさっきまでは起動していたのに、 「オンライン」にすることによって起動しなくなってしまった。

どうやら、クローンしたドライブには、 windows が管理するための ID もクローンしている状態になるので、 クローン元とクローン後のドライブ両方を接続した状態で起動すると、 ユニークであるはずの ID が複数ある状態はまずいので「オフライン」になっていたようだ。

そして「オンライン」にすると、 その辺りの情報が矛盾しないように書き換えが起るらしい。 そして、その書き換えによって OS が起動しなくなる。

これを解決するには、bcd を書き換えてやる必要がある。

bcd の書き換え

bcd の書き換えには、回復コンソールで作業する必要がある。

回復コンソールは、windows のインストールメディアを使うのが確実。

インストールメディアで起動し、 インストールではなく修復を選択し、コンソールで作業する方法を選択する。

回復コンソールに入ったら、次の順に作業する。

  • システムボリュームにドライブレター C を割り当て
  • bcd の修復

以降、それぞれのステップについて説明する。

システムボリュームにドライブレター C を割り当て

修正したいシステムドライブのドライブレターが C になっていないと 今後の作業が正常に動作しないので、まずはシステムドライブに ドライブレター C を割り当てる。 なお、作業する際は、修正したいストレージ以外は出来るだけ外してから作業する。

  • diskpart を実行
diskpart
  • ドライブの確認

    • 以下を実行し、修正するドライブの番号を確認する
DISKPART> list disk
  • ドライブの選択
DISKPART> sel disk 0  ← 確認したドライブの番号
  • volume の確認

    • 以下を実行し、修正するシステムボリュームの番号と、ドライブレターを確認する
DISKPART> list volume
  • ここでシステムボリュームにドライブレター C が割り当たっていない場合は次に進む
  • 別のボリュームにドライブレター C が割り当たっている場合、次を実行
DISKPART> sel vol 0 ← C が割り当たっているボリューム番号
DISKPART> remove letter=C
  • システムボリュームを選択
DISKPART> sel vol 0 ← 確認したシステムボリュームの番号
DISKPART> assign letter=C
  • diskpart を終了
DISKPART> exit

bcd の修復

以下を実行

bootrec /scanos
bootrec /rebuildbcd

以下で確認

bcdedit /enum

以上。