Windowsのドライバが何故か組み込まれなくなってしまったら。

 今回は稀に突然発症する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以下のファイル不整合は相変わらず発生し易いので、大多数はドライバの不整合だけ直せばどうにかなるのではないかと。

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

Share

Win10のKB3124200、病気持ちにつき注意。

 昨日辺りからWindows Updateに乗ってきたKB3124200だが、適用された環境でコントロールパネルを含む一部アプリが起動出来なくなる不具合が発生中。
 このテの症状はレジストリが壊れたりシステム必須ファイルが壊れたりしても発生するのだが、該当KBを明示的にUninstallすると全ての症状が消えることから、このKBが病気持ちなことはほぼ確定。

 対策は該当KBをUninstallすること。繰り返しになるが、それで問題は解決する。

 ◇

 コレでS.KazがWindows10のWindows Update絡みで喰らったトラブルは2回目。 
 1回目はTH2で出たDigiOn製品の不具合で、前回書いた通り。
 2回目がコレ。

 さて・・・3回目は何時来ますかね。

Share

リモート デスクトップ サービスは別にビジーではありません。

 今回のネタは、時々「あ~やっちまった」となるお話。

 Windows Serverでログインしたまま(そして大抵は何かアプリを動かしたまま)のセッションに再接続しようとすると、たまにこんなエラーが出て接続させてくれないことがある。

 「リモート デスクトップ サービスが現在ビジー状態のため、実行しようとしている操作を完了できません。しばらくたってからもう一度試してください。他のユーザーはログオンできます。」

 ちなみに英語版のエラーメッセージはコレ。

 「The task you are trying to do can’t be completed because Remote Desktop Services is currently busy. Please try again in a few minutes. Other users should still be able to log on.」

 この問題が出てしまった時の対処法は、

 「Adminユーザーでログインして該当ユーザーを強制ログアウト」

 これが一番。というか、実質的にはコレしかない。

 え、保存していないデータ?セッション切る前に保存していなかった方が悪い。
 だってWindowsよ?いつ落ちてもおかしくないでしょ?それぐらい覚悟してるよね?

 ・・・え、鬼畜過ぎるって?
 でもこんな風に割り切りでもしないとどうにもならないのも事実なワケで。
 さくっと強制ログアウトしてしまいましょ。

 ◇

 さて、頻度は低いとはいえ一度ブチ当たってしまうと状況次第では(精神的、或いは時間的)ダメージが結構大きいこのトラブル。
 一番アレなところは、エラーメッセージが実態を全く正しく表していないことなのではないかと。

 というのは、殆どの場合、問題なのはTermSvcs(Remote Desktop Services)ではなく、その上のセッションで動いているCsrss.exeがセッション接続要求に応えなかったからなんですな。

 そもそもcsrss.exeって何かと言われると、カーネルとアプリケーション間のやりとり(システムコール等)を仲立ちするシステムサービス。Windows起動と共に開始され、サービス開始に失敗する(或いはユーザが間違って停止させる)とBSODで即落ちする、Windowsの基幹部品の一つ。
 なので、アプリが起動する際には必ずこのcsrss.exeとのプロセス間通信が発生しているし、ユーザーがログイン・ログアウトする際、セッションが接続・解放される際にも然り、と。

 ところが、デスクトップ用に作られてあまりセッション切断のことを考慮していないアプリがあると、セッションが切断された際にアプリとcsrss.exeの間でデッドロックが発生してしまうそうな。状況的には、カーネル側に対してはセッション切断を完了しているが、アプリ側のセッション切断完了は待ち続けているという。
 仮にcsrss.exeがアプリにセッション切断を強制したらアプリが即ハングする可能性もあるので、さすがにそういう仕様にはなっていない。

 この状態でもシステムコール等は正常に出来るし、アプリ自体は特に問題無く動き続けるが、csrss.exeの方は「セッション完了待ち」ステータスで居続ける為、新しいセッション接続要求に対して対応することが出来なくなってしまう。

 #ちなみにWindowsServer2008/R2にはこのデッドロックが頻発する不具合(バグ?)があり、修正パッチが出ているものの、これも根本解決ではなくタイミング調整等でデッドロック頻度を下げているだけ、の模様。

 ◇

 それじゃコレ、正しくお行儀良くセッション切断するアプリなら問題無いか、というとそう簡単な話でもないようで。
 何しろ「純正」MS製のOffice等でもこのデッドロック状態が発生することがある、という話はぼろぼろ出てきているので。

 不具合発生頻度が結構高くよくネタとして出てくるのはOutlookで、デカいメールボックスを抱えているようなユーザー。
 Outlookのプログラム自体はこのセッション切断を考慮していないワケではないようなのだが、メールボックスに対して検索等の操作中だったり、裏でインデックシングが動いているような状況で切断すると、アプリ側のセッション切断がシステム側の要求に対して間に合わず、デッドロック状態に陥ることがある模様。

 他にも、たまたまIO要求が高い状態でセッション切断すると、通常なら一瞬で終わる筈の処理がIOに引っ張られて待ち行列に入ってしまい、結果的にタイムアウトしてデッドロック状態になるというハメに陥ることも。

 ◇

 ということで、元々「シングルセッション」「全権限制約無し」「起動中にセッション切断・再接続なんて考慮外」という世界で動いていたWindowsのデスクトップアプリを、Server上で動かすってのは意外とリスキーである、というお話でしたとさ。

 まぁ自分の場合は「あっちゃーまたかよ」で済むので特に対策もせず使い続けているが、そういうのが許されない状況だったら、悪いことは言いません。
 Server上でデスクトップアプリを動かすなんてことはやめといた方がいいです、はい。
 そしてどうしてもデスクトップアプリを起動しなくてはいけなくなったら、終了するまでセッションはそのままで。

 P.S.
 個人的には出来はそんなに悪くないと思っているNT6.3カーネルなのだが、その中でも恐らく手癖として最悪なのがコレ

 「IOのプライオリティが高い割に、IOと要求スレッドの並列化が十分になされていない」

 ではないかと。
 結果として、該当スレッドの処理内容とは関係無い筈のIOの待ちでスレッドが何故か一時停止したり、平行稼働出来る筈のIOが何故か順次稼働になってしまったり。
 プライオリティを上げないとIO性能が頭打ちになるのは目に見えていたのでこの変更自体は正解だと思っているが(これからコンシューマーでもNVMe等が普通になっていくだろうし)、伴ってもう少し改善すべき箇所もある気がするのよね。

Share

UEFI bootでディスクのSerial Noを変えて起動しなくなったら。

 検証用に大量の物理・仮想マシンを並べたりする時によく使われる、クローニングという手法。
 仮想マシンだと特に簡単にコピー出来るので、さくっと出来て嬉しいことが多い反面、気をつけなくてはいけないこともあるワケで。
 そんな中には、従来の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になっていないとこのコマンドはエラーになってくれるので。

Share

ヘンな名前のファイルが削除出来なくて困ったら。

 超絶今更っちゃ今更ネタなのだが、ちょっとドツボってる場面を見かけたので。

 WindowsのFileSystemAPIはまぁ実に実装がテキトーというか何というかなので、普通にエクスプローラやコマンドプロンプトからは扱えないファイル名のファイルも簡単に作れてしまう。
 まぁそれ自体は兎も角として、世間にはアンインストールしてもそういうファイルを残していくとか、挙げ句テンポラリファイルとしてそういうNGファイル名を使ってる為に、何かの拍子でテンポラリファイルが残ってしまうとアンインストールがエラーになるというヘボ実装のアプリが存在するのであり。

 で、そんなファイルを削除する方法。意外と知られていないらしいので、メモ代わりに書いておく。

 DOS窓を開いて「del ”¥¥?¥ドライブレター:¥フルパス¥ファイル名”」

 ※勿論「¥」は半角で。blogで半角にすると「\」に文字が化けてしまうので。

 ポイントは「¥¥?¥」の部分。
 これはWindowsが持つ特殊パスの一つで、通常使われるpath名展開・正規化エンジンをバイパスするもの。
 なので、通常は正規化されてしまい手が出せなくなるヘンなファイル名やフォルダ名も指定出来るようになる。

 逆に言うと、カレントパスを示す「.¥」等の特殊表記、パス記述での区切り記号(¥)の重複や代替区切り文字の使用(/)等は全てこの正規化エンジンが展開しているので、この指定方法を使うと全てNGになる。

 #なので、スクリプト等で厳密にパス名を検査したい場合に使ったり。

 ちなみに当方が見かけたのはCygwinをテキトーに入れてテキトーに削除しようとしてドツボってた場面。
 「REAME.」(←このファイル名の最後の「.」が問題)なるファイルが残ってしまい、エクスプローラから削除出来なくなる模様。

Share