XTS-AESが漸く使えるようになったのでBitLockerについておさらいしてみた。

 さて、本日はBitLockerのお話でも。

 Windows10 1511では結構あちこちに手が入っているのは周知の事実。
 その中でも、個人的にはかなりの注目ポイントだと思われるのに、世間では全く取り上げられていないネタが一つ。

 「Windows10 1511からBitLockerでXTS-AESがサポートされた」

 漸くというか何で最初から無かったのといか、そういうレベルではあるが。

 これでBitLockerも漸く「世間並の暗号化強度」と胸を張って言えるようになりました・・・のだが。
 これが世間で全く注目されないということは、やっぱりストレージ暗号化なんて世間では全く流行っていないってことよね、コレ。

 一方で、従来Windows8から使われてきたAES-CBCについて、何だか微妙に誤解されているような雰囲気も。

 ということで、今回はBitLockerの歴史と暗号強度の話でもしてようかと。

 ◆

 まず、暗号化ってのは当然ながら強度が高い方がいい。
 但し実際には互換性や処理能力からどこかで「妥協」が発生するので、実際にはこの「妥協」点が適切か、という話になるのですよ。

 ◇

 ということで、まずは初代BitLockerから。
 いわゆるNT6カーネル→Windows Vista~7、2008~2008R2にて実装。

 暗号化モードはAES-CBCで128bit(こちらが標準)または256bit、更にElephant Diffuserが標準で付いてくるが、使用しない設定も可能。

 最大の特徴はElephant Diffuserという難読化(というか掻き混ぜというか)アルゴリズムを使っていることで、AES-CBCにおける攻撃耐性の弱さをこれでカバーしている。
 一方で欠点もElephant Diffuserに存在し、何しろコレはAESのような標準化された手法ではないのでハードウェアアクセラレーションが効かず、結果としてBitLockerの重さの主原因となってしまったと言われている。

 ちなみにこの初代BitLockerの詳細についてはMITのサイトに公開されているMSの論文(https://css.csail.mit.edu/6.858/2013/readings/bitlocker.pdf)にかなり詳しく書かれているので興味ある方は一読を。

 ◇

 次は2代目BitLockerから。
 いわゆるNT6.1カーネル→Windows 8~8.1、2012~2008R2にて実装。

 暗号化モードはAES-CBCで128bit(こちらが標準)または256bitのみ。
 恐らく速度を優先するために、Elephant Diffuserのサポートをしれっと切ってしまったというのが最大のポイント。標準として使用しないとしても選択肢として残すぐらいしておけば良かったのに、サポート切りってどうよ、と。

 さてそれではAES-CBCの何がそんなにマズいのか。

 先程も「攻撃耐性の弱さ」と書いたが、「特定の状況」では簡単に突破して解読出来てしまうのですよ、AES-CBCって。
 しかもこの「特定の状況」、攻撃者は暗号化キーを知る必要が無いという。

 これだけ訊くと「それじゃ暗号の意味ないじゃん」という方、ちょっと待った。
 この「特定の状況」って、攻撃者は暗号化キーこそ知る必要はないものの、それ以外の状況は結構特殊なんですよ。

 その特殊な状況というのは、攻撃者は暗号化キーは知らないが、最低限復号されたデータにはアクセス可能、というもの。
 個人ベースで一つの環境を占有していればこういう状況には遭遇しようがないが、一方でエンタープライズ系で集中鍵管理やっていたり、家族みんなで同じ環境使ってますなんて環境だと想定しうる事態なんですな。
 そのような状況では、例えば権限管理が甘いor突破されてしまうと、本来読めてはいけない筈のデータが読めたり書き換えできてしまったりする可能性があるんですわ。

 これがAES-CBCの攻撃耐性の弱さなんですな。
 エンタープライズでは複数のユーザーが権限を使い分けるなんて当たり前なので、こんな調子じゃとても許容し辛い。
 なので実際に(ディスクの暗号化が必要な)大多数の企業では、サードパーティ製でXTS-AES等の強度の高い暗号化が出来る専用ツールが導入されていたりするんですな。

 逆に言えば、個人が自分専用で使うUSBメモリのようなメディアなら、AES-CBCでも事実上十分な暗号化強度を持っていまっせ。そういう使い方ならアルゴリズムよりもキーの方の強度を心配しましょう、はい。

 ♯いくらAESが突破不能でも、辞書攻撃や総当たり攻撃で暗号化キーがあっさりヒットするようでは元も子もない。

 ◇

 そして3代目BitLocker。
 実装はWindows10 1511以降。WindowsServer 2016でも標準サポートしていると思われるが未確認。

 最大の特徴はXTS-AESを採用したこと。
 IEEEで標準化された暗号化アルゴリズムを採用することで、最近のCPUが備えるハードウェアアクセラレーションを活用してElephant Diffuser以上の難読化を高速に処理することが可能となった上、FIPS等の他の規格にも準拠し易くなったという良いことづくめ。
 勿論、エンタープライズの世界でも使い物になる。

 欠点はというと単純に昔の環境では見えないということぐらい。

 ちなみにWindows10 1511以降でしか使用しない前提ならば、XTS-AESを使用した方がAES-CBCより処理速度が速い上、強度も高いので選択しない理由は無い。
 ついでに言うとデフォルトはAES128のままだが、ハードウェアアクセラレーションが効いている環境ならAES256にしても誤差程度しか処理速度に差が出ないので、そちらに変更することをおススメ。

 ◆

 最後に、実際の設定方法。ポリシーで設定すること可能だが、個人的にはレジストリで。

 HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE

 EncryptionMethodWithXtsFdv [DWORD] ←固定ドライブ
 EncryptionMethodWithXtsOS [DWORD] ←OS起動ドライブ
 EncryptionMethodWithXtsRdv [DWORD] ←リムーバブルドライブ

 1 →AES-CBC 128 /w Elephant Diffuser (Vista/7 Only)
 2 →AES-CBC 256 /w Elephant Diffuser (Vista/7 Only)
 3 →AES-CBC 128
 4 →AES-CBC 256
 5 →XTS-AES 128 (W10 1511~)
 5 →XTS-AES 256 (W10 1511~)

 ということになっております。
 ちなみにポリシーで設定する場合の場所はここ。

 グループポリシーエディタ(gpedit.msc)起動
 コンピューターの構成→管理用テンプレート→Windowsコンポーネント→BitLockerドライブ暗号化

 ・ドライブの暗号化方法と暗号強度を選択する(Windows8、Windows Server2012、Windows8.1、Windows Server2012 R2、Windows 10 [Version 1507])
 ・ドライブの暗号化方法と暗号強度を選択してください(Windows 10 [Version 1511] 以降)
 ・ドライブの暗号化方法と暗号強度を選択する(Windows Vista、Windows Server2008、Windows7、Windows Server2008 R2)

 ・・・この翻訳の揺れは何。

 ◆

 以上、本日はこんな感じで。

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のKB3140768、環境修正もやっている模様。

 今回はだらだらと長いのでまず3行まとめ。

 ・Win10のKB3140768は既存環境の修正も入っている模様。
 ・今までの累積パッチが入らなかった環境でも入るかも。
 ・S.Kaz手元の1~3月累積が入らなかった複数環境には全て入った。

 ということで、以下だらだらと。

 ◇

 さて、管理人の手元にはKB3140743の当たっていないWin10環境が複数存在しております。
 揃いも揃って使い込んだWin7からのIn-Place Update環境ということでまぁ環境が汚いというのはあるとは思うが、にしても毎回当てようとして失敗するので、MS謹製ツールで取り敢えず隠してしまったり。

 ところがここで更なる累積パッチというか、内容的には事実上修正アップデート的なKB3140768なるものが来ましたよ。
 まぁこれも今まで通りの累積だから当たらないよね・・・ほらやっぱり。
 コレ以外のパッチは全て問題なく当たっているのも、ある意味予定通り。

 ということで「こりゃRedStoneが出たら腹決めてクリーンインストールでもするしかないかねぇ」とか思っていたんですよ。
 何故って、これらの累積パッチが入らない環境は揃ってここまで全てsfcでもdismでも問題は検出されていなかったのです。

 ♯にも拘わらずうち1台に修復インストールかけてみたところ、最初のリブートの後暫くして黒画面でハングし、リセットボタン押すと環境復旧が始まり「0xC1900101 – 0x3000D MIGRATE_DATA 操作中にエラーが発生したため、インストールは FIRST_BOOTフェーズで失敗しました」とか出てる始末でして。

 ・・・取り敢えず、毎回のお約束を叩いてみますか、と。
 今回も「整合性エラーは出ないのにパッチが当たりません」という状況の確認ということで。

 >sfc /scannow
 >Windows リソース保護は、整合性違反を検出しませんでした。

 問題なし。ほらやっぱり。

 >DISM.exe /Online /Cleanup-image /Scanhealth
 >復元操作は正常に完了しました。
 >操作は正常に完了しました。

 ・・・え?!
 これ何か障害があった時の表示よ?
 今までずっと無問題で来ていたのに、何故?

 それじゃ念の為、もう一度sfcかけてみるか。

 >sfc /scannow
 >Windows リソース保護は、整合性違反を検出しませんでした。

 やっぱり問題なし。だよね。
 何だったんださっきの。

 とか言っている間に、裏ではWindowsが勝手にもう一度KB3140768を当てていますよ。
 無駄な努力だというのに・・・。
 とはいえさっさと再起動しろとか言ってきているので、まぁ再起動しますか。

 ・・・(数分経過)・・・

 あれ?
 KB3140768当たってしまったよ?
 Winver見たら10586.164になってるよ?

 ◇

 ・・・ということが複数環境で発生しまして。
 どれもパターンは一緒で、

 最初にKB3140768当てると失敗する
 →その後dismかけると今まで出なかったエラーが出る
 →その後もう一度KB3140768当てると成功する

 これはもう再現性があると言っていいのでは。

 ♯どの環境もWin7からのアップデートというのは気になるけど。

 実はdismで修復メッセージが出たというトコにはついては、微妙に心当たりがあるのであり。
 というのは、エラーの出方やログから.NET Framework周りの環境不整合はありそう、というぼんやりした目途を付けていたので。

 ♯それに.NET周りがおかしくなっている可能性のある場面なんて今まで散々あったし。

 そうなると、今まで壊れていたにも関わらずエラーとされてなかった部分が今回正しくエラーとされ、dismで修復され、環境が整ったので累積パッチが当たりました、という分かり易い説明が成り立つので。

 ◇

 以上、こんなこともありました、という話でした。

Share

2015年のPC業界を個人的に振り返る。

 さて、書いていたらまたしてもあまり面白くない感じになってしまったのが本人をしてイマイチなのだが、取り敢えず今年のPC周りを振り返ってみましょ。

 1◇Windows10の提供開始とゴタゴタ。

 今年のPC業界全体を見ると、落ち目のMicrosoftに振り回されて業界全体が更に弱った、というのが個人的印象。

 トップが変わってから色々頑張っているのは分かるのだが、多少頑張った程度でMS品質がどうにかなるワケもなく。
 しかも何故か当初予定より前倒しで展開した挙句、相変わらずのポンコツ状態で「正式」登場したWindows10。

 ♯もう少し品質を上げておけばもっとスタートダッシュが効いたと思うのだが、ここまで前倒しにした理由が個人的には全く思いつかないんよ。

 そして先日配信されたNovember Update=事実上のSP1でもバグ修正と仕様変更を一気出し、しかも配信できちんとトラブルを起こす、という相変わらずの展開。
 とはいえ漸く「SP1並」の品質になってきたので、EarlyBirdがぼちぼち移行し始めているといったところ、というのが2015年末ってトコですかね。
 次の大型アップデート=Redstoneではまた色々手を入れるという話もあるので、取り敢えずここで一旦、という人も居るのでは。

 とまぁここまでの展開が約半年。
 ユーザもPC業界もそろそろ学習しましたね。Windowsは未来永劫安定することはない、と。
 そしてトップが変わろうがアグレッシブになろうが、やはりMicrosoftは品質とタチが悪いと。

 変化することと安定しないことは違う筈なのだが、Microsoftにこの2つを区別出来るだけの能力があるワケもなく。
 Micfosoftが目指すと公言したモノと、現実とのギャップが激し過ぎて、でも業界としてはそれに付いていくしかない。

 しかも一蓮托生だと思っていたら、自社製ハードウェアのラインナップ拡張で競合範囲を広げてきたし。
 更にTH2の出来云々よりも強引なアップデート誘導という面で個人ユーザとベンダの余計な混乱と反発と顰蹙を現在進行形でかっているし。

 そんな姿勢そのものがPC業界を弱らせているということに、MSは気付いていなのでしょう、きっと。

 ちなみにWindows10 Mobileは・・・あ~そいやそんなのありましたね的な。
 個人的にはこのまま永遠の弱小勢力で終わる確率が非常に高いと思っています。
 OS提供も遅れ、Windows Bridgeも全然進んでいない、その間にもAndroidとiOSは拡大中、もうこの差はは取り返せないだろ、と。

 確かに最近のAndroidは肥大化というか品質低下が目立っているし、その辺りWindows10 Mobileと並べるとという話もあるが、OSとしてのプラットフォームが一度広まってしまったらソレがどれだけ強いかということは、Microsoft自身のWindowsが証明してきたトコなのでね。

 ♯ネタ商品的にはアリだと思う。

 2◇OneDriveを巡るゴタゴタ。

 Microsoftネタ連発だが、これも今年のデカい話として外せないと思うので。

 ミクロで見ればいつものMicrosoftというだけ。「新生」Microsoftは存在しなかった、ということを一番分かり易く知らしめたということで。
 マクロ的視点だと、クラウドサービスってこういうモノだよ、ということを広く再認識させた効能があったかと。
 一般PCユーザの視点で見てみると、Microsoft離れを加速させたとしか。

 個人的な意見だが、古臭いPCユーザといわゆるスマホネイティブユーザの大きな違いの一つに、サービスに対する忠誠度があると思っている。
 これはPC万能時代の「移行の面倒臭さ」の記憶と裏返しであり、一つのアプリなりサービスなりに腰を据えて使い続けるのがPCユーザの習性。良く言えばロイヤリティが高い。
 一方、スマホネイティブユーザはアプリを選んで入れて捨てて御仕舞が当たり前。大多数がコンテンツ消費者なので移行するデータも無く、データ移行作業なんて基本存在しないので、アプリを入れ替えても特に困らない。
 サービス提供側から見た場合、どちらを掴んでおいた方が幸せか、ということですよ。

 そんな時代に、コンテンツ消費者がPCを買ってくれるという幻想はもう通用しない。
 PCが掴んでおくべき顧客はひと昔前「プロシューマ」と呼ばれていたコンテンツ作成側のユーザであり、これは即ち古臭いPCユーザであり、取りも直さずWindowsユーザであり、Microsoft製品ユーザなのですよ。
 そんな彼らに「やっぱMicrosoftは信用ならんわ」と知らしめた今回のイベントは、確実にMSのコンシューマ向け戦略に未来永劫影響を与えると思うんですわ。Windows Mobileの展開も含めてね。

 3◇メインストリーム向けNVMe離陸開始。

 さて、いい加減MSネタばかりだと飽きるので、きちんとハードウェアの話しましょ。

 今年のハードウェア的トピックの中では、個人的にはNVMeがいよいよコンシューマ向けに来たことかと。
 OS側は実はWindows 8.1からフルサポートになっていたが、チップセット側の正式サポートが100シリーズからとなったので、DDR4移行と同時のタイミングで離陸開始と。

 そんなNVMeの価値は、世間で良く言われている「ベンチマーク値がSATAの理論速度超え」ではなく、プロトコル上のオーバーヘッドが少なくSATAよりレイテンシが低いこと。
 今は未だ出始めということでコストも拡張性も全くこなれていないが、現状CPUの足を引っ張りまくっている大容量記録装置周りが漸く一歩前進したワケで。

 個人的には是非早期の値崩れを期待したいところだが、同時にIntelにPCIeバス本数拡大も期待したいところ。
 NVMeだとPCIe x4を使ってしまうので、現行CPUのPCIe x16では拡張性が足りないよね、と。

 4◇HBMが実製品に。

 次に、今年HBM搭載製品が(ハイエンドとはいえ)一般向けに出回り始めたのは、あまり世間では話題になっていないが個人的にはポイントだと思うのですよ。

 着目点ととしてはNVMeと一緒で「高速な演算装置と、追い付いて来ない周辺回路」というPCの中の構図を一歩改善する為に、非常に広帯域なメモリが採用されたということ。
 勿論現時点では価格その他問題も色々あるが、AMDはAPUでもメモリ帯域不足で頭を抱えているということ、GPU ComputingにはPCI-Expressも相対的に低速でボトルネックとなっていること、その他諸々を考えると、まずは将来に向けての一歩を踏み出した、と言えるのでは。

 5◇HDDもSSDも揃って停滞中。

 続けて大容量記憶装置の方を見てみると、今年は正直停滞の年でした、と。

 まずSSDは順調に値下がりし、年初比で3割~4割安くなったが、正直それだけ。
 低価格品ではTLCの採用が拡大。TLC故の書込の遅さはキャッシュで誤魔化すしかなくその取り回し方法で多少個性が出るものの、基本的にはコントローラが一緒なら挙動も一緒という、正に「コモデティ」と化してきたというところ。

 HDDの方を見てみると、コンシューマ向けには年初に8TB品が出回り始め、年内で大体3割程値下がりしたものの、10TB品は未だに影も形も見えず。
 アキバの店頭では地味に4TB・5TBが下がったものの、今年1年ずっと3TBが主役のままで、このラインに至っては値動きもほぼ無し。

 以上、要するに全く面白くなかったですな。

 ちなみに、現時点でPMRの最高密度品は東芝の2.5′ 3TB HDDの750GBプラッタ。
 製品発表は年初、その時は5月出荷予定とアナウンスされ、アキバには9月に流れ始めましたな。これが最高密度。
 3.5’ではHGSTの10TB製品で、コレは1.43TBプラッタという密度。SMRでは去年この密度になっていたのだが、今年にはPMRでこの密度になりました、と。

 あとペーパーではSMRではSamsungが2.5’で1TBプラッタを開発したとPRを出ているが、現物はちっとも出てこないですな。

 6◇IntelがSkylakeでDDR4に移行開始。

 最後にIntelからSkylake登場、DDR4に移行を開始しました、と。
 ある意味定例アップデートで面白くもなんともないし、消費電力は減ってきているものの実処理性能ではあまり伸びてもいない。
 これは取りも直さず「アップデートのメリットが少ない」=「コストばかりかかる」=「コスパが悪い」ということで、こういう商法を続ければどうなるか・・・は自明の筈なんだがなぁ。

 但しプラットフォーム入れ替えというのはパーツ屋にとっては一大イベントで、これがあったからPCパーツ屋は今年が乗り切れたなんて話もあったり無かったり。

 ♯「DDR3が使えるSkylakeマザーが動かない(売れない)」なんて台詞をどっかで聞いたが、当然でしょうよ。

 ◇

 以上、今年のPC市場は自分から見たらこんな感じでした。
 今年のblog更新はこれで終了です。

 それでは皆様、良いお年を。

Share

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

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

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

 ◇

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

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

Share