今回は稀に突然発症する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になっていないとこのコマンドはエラーになってくれるので。