今回は稀に突然発症するWindowsの病気、「何故かドライバがインストールされない病」のネタでも。
　何でこんなネタを出したかというと、自分の端末が喰らってしまったから。

　◇

　まず、この症状の解説から。

　「ある日突然、それまで使えていたUSB等の機器が認識されなくなった」

　これが病状。
　ってさらっと書いているが、これ結構致命的で、使い方次第ではこうなったらPCが役立たずになってしまうことも珍しくない。
　例えばUSBメモリなんかが、昨日まで使えていたのに今日突然使えなくなった、とか。
　まぁメモリ程度なら兎も角、データ山盛HDDなんかだとかなりシャレにならないことに。

　なので、ここからは原因切り分けを開始ということで。
　まずは、デバイスマネージャを起動。この時、

　「何故か使えないデバイスが「ほかのデバイス」というトコに繋がっているように見える」

　この状況の場合、この病気の可能性が高い。
　逆に、そもそもデバイスが見えていない場合はハードウェア故障の確率の方がかなり高い。
　次にイベントビューアをチェック。

　「「Windowsログ」「システム」の中に「情報」として「イベント20001」が「UserPnp」から出力されている」
　「「ドライバー NULL Driverをインストールするプロセス」というメッセージが見える」

　上記状況にヒットしてしまった場合、ほぼ100％今回の病気ですな。

　◇

　さて、この病気の原因なのだが。

　一言で言うと、HDD上のドライバ情報またはドライバ本体が壊れてしまった為。

　Windowsには悪い癖があって、この「ドライバ情報」というのは意外と壊れ易い。
　そしてこの「ドライバ情報」が壊れてしまうと、ドライバ本体まで使えなくなってしまう。
　更に悪いことに、この状態でドライバ自体を修復や再インストールしようとしても「ドライバは問題ありません」とか言われて蹴飛ばされてしまったりする。

　＃ちなみにドライバ情報にはキャッシュ（のようなもの）があるので、そのキャッシュが捨てられて再構成されるまではドライバ情報が壊れていても特に問題は発生しない。なので、実はとっくの昔に壊れていたものがある日突然明るみに、というパターンは少なくない。

　こんな状況を打破するには、要するに壊れたドライバ情報を修復するしかない。
　修復手法は2ステップ。

　但し以降に書くこの方法、システムが壊れかけている場合はとどめを刺すことになる可能性があるので、システムフルバックアップを必ず取ってから実行すること。
　一見治っているように見えて実は他のトコが巻き添えで壊れた、なんてことも実際あるので。

　＃たまに「取り敢えずコレ打て」的な書き方を見かけるが、取り敢えずで打つ程安全なコマンドではないよ念のため。

　◇

　まずは事前準備。

　chkdsk /f C:
　（Windows10では chkdsk /f /offlinescanandfix C:）

　システム障害が起こっている環境ではかなりの確率でシステムドライブに論理エラーが出ていることが多い。
　それを放置したまま次の作業を進めてしまうと更に傷口を広げてしまう可能性があるので、まずはそこを潰しておく。
　但しこのコマンドの時点で既に打つ手なし状態だと判明する確率も実はそこまで低くはなかったりする。

　＃ちなみに物理エラーが疑われるなら/rで。環境次第ではやったら時間はかかるが、そういうモノ。

　そして軽い方から。コマンドプロンプトから以下のコマンドを打つ。

　sfc /scannow

　Windowsのシステム修復機能を起動して、壊れているコンポーネント情報を修正するコマンド。
　修復はあまり期待出来ないが、エラーが出たら基本的に何処か壊れている。
　ちなみに環境にもよるが30分とか普通にかかる。

　Windows7迄の場合はここまで。
　Windows8以降では次のdismコマンドも打っておく。
　こちらはWindowsのImageを掃除するコマンド。
　詳細は横に置いておくとして、これもそこそこ時間かかる。

　DISM /Online /Cleanup-image /Restorehealth

　で、上記2つのコマンドを実行した後、再起動。
　その結果・・・改善することもあるが、環境よっては却って悪化することも。
　その場合は諦めて次へ。

　◇

　次に、手間のかかる方。
　まずこの手法を使う場合、

　・正常なドライバ
　・空きHDD
　・WindowsのインストールDVD

　この3点が存在することが大前提。
　ではこれらで何をするかというと、

　1. 現在の問題あるHDDを取り外し、空きHDDを取り付ける。
　2. Windowsをインストールして起動出来るようにする。
　3. 問題あるHDDを接続し、問題あるWindowsパーティションを見えるようにする。
　4. パーティション内からドライバの格納先を探し、インストール直後の正常なドライバで全て上書きする。
　5. 環境を戻してデバイスを認識させる。

　こうなる。
　ちなみに5.のデバイス認識では通常より時間がかかることがあるがそれは正常。

　以下、4のステップの詳細。

　・ドライバの保存場所は大体のマシンでC:￥Windows￥System32￥DriverStore￥FileRepository。
　　この下にドライバ毎にフォルダが切られていて、このフォルダ名＝ドライバのinfファイル名。

　・このドライバ毎フォルダ内にはinfと対になるsysファイルやdllファイルが保存されている。
　　何かの拍子でこの中のファイルが壊れたり不整合を起こしてしまうと、ドライバのインストール不良になってしまう。

　・Windows標準ドライバでこの症状が出た場合、同一Windowsの正常な環境からフォルダ内ファイルまるごと全コピーで上書きしてしまうのが簡単。
　　サードパーティ製ドライバならドライバディスクやインターネットからコピーして入れ直す。

　・そのままだと上書き出来ない場合は、一旦ファイル・フォルダの所有者を自分に変えてから権限を付けると作業可能。
　　ローカルの管理者権限を持っていれば所有者の変更だけは出来るので、所有者変更→権限付加、の2ステップ。
　　勿論作業後は元通りにしておくこと。

　◇

　以上、こんな作業でWindowsでの「デバイス認識しない問題」「ドライバが何故か入らない問題」の大多数は片付く。

　勿論これで全部直るワケではなく、例えばレジストリが壊れていたりするともっと大事で、そこまでいってしまうと再インストールの方が幸せになれる。
　だがレジストリ自体の不整合は最近はかなり発生しづらくなっている一方、DriverStore以下のファイル不整合は相変わらず発生し易いので、大多数はドライバの不整合だけ直せばどうにかなるのではないかと。

　とまぁこんな感じで、今回はここまで。

　検証用に大量の物理・仮想マシンを並べたりする時によく使われる、クローニングという手法。
　仮想マシンだと特に簡単にコピー出来るので、さくっと出来て嬉しいことが多い反面、気をつけなくてはいけないこともあるワケで。
　そんな中には、従来のBIOS環境だと気にする必要が無かった、UEFI環境ならではのネタもあるワケです。

　そんな中で今回ネタにするのは、割とありがちな「ディスクのシリアルID書き換えたら起動しなくなった」という話。
　自分も初めてやらかした時は「あちゃ～」という感じだったので。

　◇

　まず、前提。

　状況：

　UEFIで起動する環境でブートドライブのシリアル番号を変更すると起動しなくなる。

　解決策：

　Step1：bcdbootで修理する。
　Step2：それで駄目なら、bootrecで修理する。

　当方が色々やらかした範囲では、ブートドライブのシリアル変更のみならbcdbootの自動修復で100％回復している。
　何も考えずに直してくれるのでこれが一番ラク。
　但し万が一これがコケた時に備えて、後で本来正当なbootrecのやり方もメモっておく。

　◇

　以下、まずはbcdbootでやる方法。

　1：
　起動がコケてるマシンをWindows Install DVD（またはUSBメモリ等）で起動し、コマンドプロンプトを開く。

　システムによってはInstall DVDよりも起動優先度が高いデバイスが存在する為、必要ならばBIOS（UEFI）画面に入って起動優先度を変更する。
　DVDから起動したらインストールオプションから左下「コンピューターを修復する」を選択し、「トラブルシューティング」→「詳細オプション」→「コマンドプロンプト」。

　2：
　diskpartでWindows SystemのあるボリュームにC:を割り当てる。

　select disk 0
　→ list volume
　→ 一覧からWindows本体が入っているパーティションの番号をチェックし、select volume 番号
　　 （例えばselect volume 3）
　　 大抵の場合Infoに「ブート」と入っている
　→ assign letter=C:
　→ exit

　3：
　bcdbootでC:から起動するエントリを作成する。

　bcdboot C:￥Windows ／l ja-JP

　4：
　DVDを抜いてシステムを再起動する。

　以上。
　実はこのうち3.のC:を割り当てる作業をせず、4.でオプション無のままでbcdbootコマンドを打つだけでも、結構な確率で起動する状態に戻せる。
　とはいえ時々コケることもあるので、ドライブレターを振っておいた方が幸せな模様。

　◇

　それでは次に、bootrecコマンドを使う場合。
　以下の例は修復フルセット。

　1：
　起動がコケてるマシンをWindows Install DVD（またはUSBメモリ等）で起動し、コマンドプロンプトを開く。

　2：
　diskpartでWindows SystemのあるボリュームにC:を割り当てる。

　3：
　diskpartでBoot PartitionにF:を割り当てる。

　select disk 0
　→ list volume
　→ 一覧からBootパーティションの番号をチェックし、select volume 番号
　　 （例えばselect volume 0）
　　 大抵の場合Labelは「システムで予約済み」、Infoに「システム」と入っている
　→ assign letter=F:
　→ exit

　4:
　Bootフォルダに入ってbootrecコマンドで再構築する

　F:
　→ 環境依存で以下のうちどれか、dir等でBootフォルダを探す
　　 cd ￥EFI￥Microsoft￥Boot
　　 cd ￥ESD￥Windows￥EFI￥Microsoft￥Boot
　　 cd ￥Boot
　→ bootrec ／fixboot
　→ bootrec ／fixmbr
　→ bootrec ／rebuildbcd

　5：
　DVDを抜いてシステムを再起動する。

　◇

　以上、こんな感じでほぼ何とかなる筈。

　ちなみにマルチブート構成ではrebuildbcdで複数のWindowsが認識され自動でエントリに追加される筈だが、時々取りこぼしも出る模様。
　所詮自動修復なので、その辺りは手修正しましょうということで。

　あと、シリアル書換でなくトラブル対応でも良く出てくるbootrec ／fixbootだが、そういう場合はWindows Systemの入っているボリューム（上の例だとC:）がActiveにマークされていることを確認することをお忘れ無く。Systemの入っているボリュームがActiveになっていないとこのコマンドはエラーになってくれるので。

　さて、当方も最近関わることも多くなってきたWindows Server 2012。
　Windows Core（Kernelとその周辺）の出来は悪くない、Hyper-Vも使い物になるようになってきた、けどまぁ兎に角UIについてはいつまで経っても慣れない、ホント最低ですわ。

　そんなWindows 2012だが、目玉機能の一つとして「記憶域」というヤツがあったのを覚えている方はどれくらい居ますかね。
　正確にはWindows 8にもあります、機能制限されていますが。

　で、この「記憶域」、確かMicrosoftはそれなりに推していた記憶があるし、お題目だけ見ると結構魅力的なんで、ストレージ絡みの話が出てくると思い出したかのように、或いはホントにふと思い出して、「どうなの」的な話が出ることがあるのですが。

　「オモチャですが」

　現時点ではこれが答えです、本当に。
　アイデアは他のブロックストレージと同じなのに、何でここまで駄目な実装なんだろうかと。

　とはいえ、腐ってますが一応ブロックストレージな訳でして。
　コア部分の出来もイマイチながら、それに輪をかけて酷いのがGUI。
　おかげで、実際にディスクが故障した際にGUIからは修復もままらないという、トンでもない事態になっています。

　＃前ネタでも書いたが、Windows8／Windows Server 2012シリーズの共通コンセプトは「クソGUI」だと本気で信じてます。

　とはいえ、実はPowerShellを使えば多少は何とかなることはあんまり知られていない模様。
　他にも、「故障したディスクを交換するには同一容量以上のディスクでなければならない」という言い方がよくされますが、これも正確な表現じゃないですよ。
　正確には

　「故障したディスクに格納されていた論理領域＋α以上の容量が物理冗長性が損なわれない複数ディスクの合計であれば良い」

　ということです。

　ということで、以下に「運用上最低限必要なのに何故かPowerShellが必須な操作」について、少しメモっておきます。
　どうしても「記憶域」を使わないといけないという事態に陥った場合にでも参照して下さい。

　1◆論理ディスクの修復

　GUIからだと何故か全く動かずエラーが消えないことが往々にしてある。あと、自動修復が発動しないことも。
　そういう時は、PowerShellから

　Repair-VirtualDisk -FriendlyName “論理ディスク名”

　で既存の論理ディスクを直ちに修復開始します。
　ちなみに、これでも駄目な時は基本的にその論理ディスクは壊れてます。

　2◆故障ディスクの削除

　何とびっくり、故障したディスクの取り外しすらGUIからだとまともに出来ないのがMicrosoft Quality。
　延々とエラー表示が残ってしまい、GUIからは復旧出来なくなることも。

　以下、その時の対処法。

　a) 既に見えなくなっている幻のディスクに対して、Set-PhysicalDiskで取外フラグを立てる。

　Set-Physicaldisk -FriendlyName “物理ディスク名” -Usage Retired

　b) Repair-VirtualDisk で既存の論理ディスクを修復する。（1と一緒）
　c) 幻のディスクを記憶域から削除する。

　もっと詳細に手順を見たい方は「もっと読む」以下に画像付で貼っておきます。
　あと、c)は基本的にGUIで出来ます。駄目な時はPowerShellのRemove-Physicaldiskで。

　3◆縮小再構成

　論理ディスク容量が当初予定より小さくなってしまった等で、物理ディスクを減らしたい時に。
　世間ではこれが出来ないと思われているフシがあるが、GUIからは出来ないだけでPowerShell使えば出来まっせ。

　a) 取り外したいディスクに対して、Set-PhysicalDiskで取外フラグを立てる。
　b) Repair-VirtualDisk で既存の論理ディスクを修復する。
　c) GUIを使用し、物理ディスクを記憶域から削除する。

　手順は故障時と同一で、違いは実在するディスク相手に操作することだけです。

　ちなみに物理ディスク容量が不足しているとa)かb)で失敗するので諦めて増やしましょう。
　記憶域の容量の割り当て方には意外と無駄が多いようで、そんなにガリガリには削れないです。

　◇

　とまぁ、今回はこんな感じで。

Continue reading “Windows Server 2012「記憶域」のGUIが全く使い物にならない件について。” →