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

以上。