【復活！ 原因編】

今回、PC障害対応に、約1週間ほど費やした。

もしかしたら、お役に立てる情報を提供出来るかも、と思い、ここに記録として残しておきます。

参考になるようであれば幸いです。

3部構成です。

【復活！ 原因編】(このページ)

【復活！ 対策編】

【復活！ 役に立ったソフト群】

まず、環境。

ASUS Zenbook UX32VD
Windows8.1無印64ビット

[事の顛末]

最初の切っ掛けは、Windows8.1が固まってしまったこと。

8月中旬のWindows Update後、あるソフトの文字部分をクリックしたところ、システム全体が固まり、どうしようもなくなった。

それが何度も発生。

これはきっとWindows Updateのせいだな、と思い、システムを復元。

しかし、その後も頻発。

Windows Updateの残骸があって、それが影響している？

Microsoftのことだから、それはありえる！ということで、システムを安定させるために、別の手段を取ることに。
(結果的に、Microsoftは関係なかった。この点ではごめんなさい。でも・・・)

別の手段とは、ちょうど出始めていたWindows10への移行。

既に予備機はWindows10にしていたし、特に大きな問題は発生していなかったので、思い切ってやってみることに。

しかーし、そうは問屋は卸さなかったようだ。

途中でアップグレードが止まってしまった。
1時間ちょっと過ぎのWindowsが起動してからの個人環境設定辺りで。

動きがなさそうだったので、とりあえず強制電源オフ。

アップグレードする前に、EaseUs Todo Backupでシステムをバックアップしていたので、それを戻すことに。

普通であればそれで問題なく起動するはずなのに、起動しない。

あれやこれややるが、どうしようもない。

ここから、復活に向けての1週間が始まったのである。

ごちゃごちゃ書くのは後にして、結論を先に。

[原因]

原因は、ハードウェアの障害。

このUX32VDのHDD構成は、ハイブリッドシステムになっていて、購入時は、HDDとiSSDという構成。

iSSDにシステムキャッシュを置き、HDDの遅さをカバーするというもの。
一昔前のReady Boostのようなもの。

確かに、この恩恵はあったので、とてもいい仕組みだと思うけれど、このiSSDが今回の問題児であった。

去年の10月に、内蔵HDDに不良セクタが発生し、システムが不安定になった。
それを機会に、HDDからSSDに移行。

そうすると、iSSDのキャッシュ機能はいらなくなる。

ネットで情報検索し、そのキャッシュ機能を無効(ExpressCacheをアンインストール)し、iSSDをWindowsから認識出来るようにした。

せっかく30GB近くあるのだから、再利用、ということで、IEやFirefox、その他のソフトのキャッシュ置き場にしていた。

そういう使い方をして、約10ヶ月。

とうとう正常に動作しなくなったようだ。

今回、その引き金となったソフトは、間接的に、iSSDの中にあるキャッシュデータを読み書きしていた。
よって、iSSDの反応がなくなって、固まり、引きずられてWindowsも固まってしまったようだ。

見かけ上は問題なさそうだったし、色んなツールでチェックしてみても、問題なさそうだった。

でも、結果的には、ハードウェア障害。

決め手は、Windows標準のコマンド、diskpartでcleanをした時にはっきりした。
そこで、I/Oエラーが発生したのである。

この障害対策をし始めてしばらくしてから、このiSSDが怪しそう、と思っていた。

その根拠として、以下のものがあった。

• HDDに不良セクタがあったり、今回のようなハードウェア障害があった場合、システムが固まる、動きが遅くなる、という現象が発生する。過去数度、これを経験済み。

• Windowsの起動が異様に遅い。
• Windowsの回復ドライブを起動しようと思っても、途中で止まってしまう。

ネットで検索してみると、このような現象が発生していて、困っている人が過去結構な数いたようだ。主に海外。
そこには、その対策についても書かれていた。

また、このiSSDのハードウェア障害が原因で、バックアップを戻しても正常起動してくれなくなった。

エラーは、エラーコード0xc0000225のブルー画面。

BCD(ブートマネージャーの設定)を直しても、絶対にこれでいいという状態であっても、このエラーや、他のなんちゃら00001の回復エラーで起動出来なかった。

時には、ASUSのロゴ画面が出て、下でクルクルアイコンが回ったままの状態。

結局は、BCDの問題だけではなく、このiSSDが悪さをしていたので、そういうエラーに繋がっていた。

この事象を確認する時にやったことで、面白い現象が幾つか。

まさかこんなことが起こるとは思わず、Windows8.1の回復ドライブは作っていなかった。

理由としては、最悪、Todo Backupで以前の状態に戻せばいい、と思っていたから。

でも、BCDを直したり、diskpartを実行するには、その回復ドライブが必要。

タイミング悪く、予備機は既にWindows10に移行済み。

Windows8.1の回復ドライブは作成出来ない。

でも、とりあえず、と思って作ってみたら、起動した！

これは本当に幸いなことだった。

但し、スタートアップ修復は、バージョンが違うということで、出来なかった。

それ以外のものも当然。

使えたのは、コマンドプロンプトのみ。

今回のブルー画面は、スタートアップ関連の問題だと最初の頃は思っていたので、なんとかしてWindows8.1の回復ドライブが出来ないか？と頭を悩ませた。

ここはWindowsの事故回復能力に頼るしかない、と。

今の僕の環境ではWindows8.1はない。

また、近所に気軽にPCを触らせてもらえる人はいない。

最悪、PCショップに行って、頭を下げるか？とまで考えたのである。(苦笑)

検索掛けていて、ふと思った。

そう言えば、Windows8.1ってISOファイルをダウンロード出来るよな、と。

それをダウンロードし、インストールディスク作成。

しかし、一番最初の言語選択画面は出るけれど、そこから先、それがインストールであれ、修復であれ、途中で止まってしまう。

結論を言えば、このインストールディスクのプログラムは、ハードウェアチェックをしていたのだろう。

iSSDから反応がない、ということで、止まってしまったのだと思う。

ガックリ・・・

他にないか？と検索をかけていると、Windows8.1のEnterprise版は、90日間試用出来るとのこと。

そうか、更にもう1台使っていないPCがあるので、余っているHDD(今回はSSD)を突っ込んでインストールし、回復ドライブを作ればいい！と思って実行。
(このEnterpriseを触って面白かったのが、インストール直後は、600MBほどのメモリ使用量だった。その軽さにすごい！と思ったのである。(笑))

しかし、そのEnterprise版の回復ドライブでも途中で止まってしまう。

余談だけれど、無印、Pro、Enterpriseそれぞれの回復ドライブの仕様って違うのだろうか？実際のところはどうなのだろう？

また、Windows10の回復ドライブでは起動出来て、同じバージョンの別エディションでは起動出来ないってどういうことだろう？

次に、とりあえずiSSDの状態を見たいので、Ubuntuで起動。

これは問題なくすんなりといった。

しかし、GParted(パーティションを操作するソフト)を起動すると、エラーが出てくる。

とりあえずそれは無視して進める。

システムドライブもiSSDもちゃんと見えている。

この時に、念のため、iSSD上の必要そうなデータをバックアップ。

問題なく救出。

Ubuntuでは見られている、というのが混乱の元ではあったけれど、その他の現象を考慮して、iSSDが一番怪しいよなぁ・・・ということで、そこに絞って調査開始。

とりあえず、ここまでまとめると、

• Windows10の回復ドライブでの起動はOK。
• Windows8.1 Enterpriseの回復ドライブでは起動不可。
• Windows8.1のインストールディスクでは起動不可。
• Ubuntuでは起動OK。
• EaseUs Todo BackupでのWindowsPEのUSB起動はOK。但し、時間がかかる。

考えて見るに、Windows8.1関連の起動プログラムは、ハードウェアチェックをしているようだ。
よって、返事のない場合は、そのまま止まってしまう。

Ubuntu起動時のインストールディスクではそれはしていないようだ。

Windows8.1の進化系のWindows10の回復ドライブでどうして起動出来たのだろうか？

Windows8.1の頃に、僕のような問題があったから、ハードウェアチェックを抑え気味にしている？

なんであれ、そういう仕組みになってくれたお陰で、今回僕は色々と調査が出来て助かったのである。

Windows8.1の回復ドライブがなかった、作れなかったのは、不幸ではあったけれど、Windows10にアップグレードしていたお陰で、元に戻せたようなもの。

何が幸いするかわからないね。(笑)

ちなみに、diskpartでやったことを。

このUX32VDのBIOS画面の中に、iSSDの情報は表示しても、それをオン／オフ出来る仕組みはない。

よって、なんとかしてソフトウェア的にオフ出来ないか？と思って、diskpartのオプションを変えて色々と実行。

まずは、iSSDの状態。

以前の状態がわからないけれど、ファイルシステムがRAWになっていた。

どうして？

Ubuntu上ではNTFSになっていたのに。

ここがまず怪しかった。

diskpart内にて、list volumeコマンドを打つと、iSSDのところになると、動作が異様に遅くなった。

次に、iSSDをオフライン状態に。

すると、今までdiskpartを起動するだけでも時間がかかっていたのに、あっさり起動するようになった。

一つ目の切り分け。

再起動をかけて、オフラインのままだったらよかったのだけれど、オンラインに戻ってしまう。

automountをdisableにしても、意味はなかった。

大事なデータはないので、怪しいと思った時点でフォーマットするなりなんなりしてもよかったのだけれど、確信が持てるまでは極力余計なことはしないようにしていた。

しかし、ネットの情報を見て、こういう状況から考えて、これはiSSDが原因だな、と思ったので、そのRAWをNTFSにしてみようと思って、clean allを実行。

すると、I/Oエラー。

cleanをしてもI/Oエラー。

ということで、これはiSSDのハードウェア障害だな、と思った次第。

障害発生から6日目のこと。

これに絞って検索をしてみると、日本側にはあまり情報はなかったけれど、海外の質疑応答サイトに情報があった。

そこに書かれていることを読んでみると、僕と同じような症状の人達が一杯。

また、記事内容は既に過去のもので、それを参考に、見事復活を遂げた人たちのコメントがいくつかあった。

但し、それを実行するためには・・・

【復活！ 対策編】に続く。