Intelの意地汚さがここまで露骨に出るとは、「Meltdown」はIntelにとって余程ヤバいものらしい。

 新年あけまして・・いきなり「Spectre」「Meltdown」脆弱性ネタで大騒ぎから始まったPC業界。何だかなぁ。

 いやね、Intelがアレなのは事実なのだが、普段なら「見掛けは」スマートに済ませるんですよ。実体は兎も角として。
 ところが今回は今まで見たことない程余りにも露骨に「オレだけじゃない」「(パッチ当てても)そんなに遅くならない」と言い訳しまくっているワケで。海外の辛口系メディアには早速ネタにされまくっているが、そこまで言い続けるということは実際には余程ヤバいんだろうなぁ~、と。

 ♯日本のPC業界は何故か病的にIntel信者が多いのでね・・・海外と日本のこの情報密度の違いよ。
  あ、ちなみに。少し前のEPYCをボロクソに言ってるスライドも(当時は)前代未聞・異例且つ中身がほぼ中傷というアレさで海外のtech系サイトの一部ではネタとして話題になったが、結局広がらなかったわね・・・中身が重箱の隅過ぎでしょアレ。

 ただでさえ、昨年末には「10nmプロセスが全然アカンのです」と自ら告白したも同然の14nmプロセスCPUコードネームの追加があったばかり。以前ネタにしたように、湯水のように現ナマを流し込むことで最先端プロセスをいち早く安定させてきたIntelをして、10nmが安定しないというのは・・・いよいよ「微細化の限界」ってヤツですな。

 あ、一部に「コストが合わないだけだ」という言い方をする人が居るんですが、半導体製造プロセスをある程度知っている人間から見ると「コストが合わない」=「プロセス開発失敗」なワケですよ。
 何故って、半導体の製造プロセスを設計する場合、一定の期間に一定のイールド(算出率・良品率)が取れることを前提にコスト構造を組み立てて「元が取れる」世界観を組み立てるんですわ。なのに「コストが合わない」=「生産した製品が想定した品質に届かない」=「作っても損しかしない」って、これ世間では「失敗」と言いますわね。
 で、Intelの場合は今まで製品をクソ高く売ることが出来たので、原価も他のファウンダリ(「ファウン『ド』リ」表記の方が一般的らしい)と比べて高く設定出来たワケですよ。そのIntelをして10nmが量産開始出来ないというのだから・・・どんだけハードル高いんだよと。

 ♯この「元が取れる」とこが見えなくてプロセス開発中止、なんてこと自体は最近では世界中のファウンダリでそう珍しいことではないんですが、昔は結構珍しかった。このこと自体開発コストが上がっていることの一つの証明ですな。

 まぁそんなこんなでIntelにとっては波乱の幕開けとなった今年。
 AMDやARMにとっては棚ぼたなのだが、皆様御存知の通りこういうチャンスをロクに活かせないのがAMDという会社だし、ARMはさすがに棚ぼたを受け止められるだけの器が未だ無い状態なので、結局Intelの絶対王政が変わることもないんでしょうな、としか。

 ♯自分はAMD派だが、AMDの商売センスの無さは伝統芸だということはきちっと認識してまっせ、えぇ。

 まぁ取り敢えず、現時点で技術的な脆弱性そのものの情報はほぼ出てきているように見えるので、後は影響範囲がどこまで広がるか観察してみましょうか、というとこですな。
 現時点の情報だと、クライアントPC系OSやアプリのようにパッチ当て易い範囲では影響は収まっていなさそうだし。

 もう一つ、これからパッチが全世界にバラ撒かれるそうなので各所から悲鳴が上がってくる様子も見てみることにしましょう。
 Linuxカーネルにパッチ当てるとWorkloadによってはパフォーマンス3割ダウンとか相当酷いことになるらしいし、既にAmazonではパッチ済みLinuxが稼働していてパッチ以前に比べてCPU負荷がガン上がりしてるとAWSの中の人が言っているし。

 あと・・・これ集団訴訟来るかね?
 主要な影響はサーバーと言いつつコンシューマーに影響が皆無というワケではない筈なので、その辺りを考えるとあの訴訟大国ならやりかねんな、と。

 とまぁこんな感じで、本日はここまで。

Share

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