RATOCのREX-SATA3シリーズHDDリムーバブルケースをお薦め出来ない理由。

 さて、昨晩、PCパーツの一つが寿命を迎えました、と。
 そのブツはRATOCのREX-SATAシリーズのHDDケージ。以前からシリンダー鍵の調子が悪かったのだが、ついに壊れて回らなくなってしまったのであり。

 それでは交換用のパーツを買って来るか・・・というところで、ふと思ってしまったのですよ。

 「あ~、正直買いたくない」

 いやね、現在のREX-SATA3シリーズって、はっきり言って他人にお薦め出来ない製品なんですよ。
 というかむしろ、自分のように「過去の遺産」として既にHDDケースを所有してしまっている以外ならば本気で「やめとけ」とユーザーの自分をして言わざるを得ないという代物なので。

 ということで、今回は実際にREX-DOCK~REX-SATAの全世代の製品を複数使い続けてきた身として、このシリーズがどれだけ駄目な製品かということをつらつら書いてみる。

 ◇REX-DOCK

 シリーズ第一作、未だIDEの頃。HDDケースもPC側に装着するケージも全てプラ製だったのが特徴。
 アクセスランプ付(全プラ製)のもの、ケースとケージの一部がアルミ製で且つアクセスランプ付のバリエーションモデル(後追いでラインナップ追加)あり。

 当時国内で「安定して供給されていた」HDDリムーバブルケースというとこの他にはOwltechが扱っていた「モービルラック」ぐらいしか無く(輸入モノは単発で入ってくるものもあったが殆どがすぐに店頭から消えてしまうという有様だった)、ある意味ニッチだが確実に需要のあるところを抑えたという感じで、地味にヒット商品に。ぶっちゃけこちらが良かったというよりはOwltechの製品がショボかった(廃熱がロクに考えられていないとか)というのが理由。

 そんなこの製品、実際買ってみたところ以下のような欠点があったのですよ。

 1.全プラ製のケージがヤワく、普通に金属製のケースにねじ止めするとケースの歪に合わせケージ自体が歪んでしまい、肝心のHDDケース(こちらも全プラ製)がうまく入らなくなる。
 ちなみにこの問題、一部アルミ製のケージではアルミ部が固いため歪は少ないもののゼロとはいかず。

 この問題には結局購入者側で対応するしかなく、結局ケースへのネジ固定を3点や2点に減らしてケースの歪から影響を受けないようにしたり、上下のドライブベイに光学ドライブのような丈夫で歪の少ないものを入れてケースの歪を打ち消したりと、設置の工夫が必要に。

 2.ケージとHDDケースの間の「遊び」が結構あってガタつく。一方でSATAコネクタ自体の場所は固定(当たり前だ)なので、HDDケースをケージに入れる時にまっすぐ入れないとSATAコネクタが上手く嵌らないこともある。
 この問題はSATA 6Gbps対応の時にケース側の構造が変わり、結果的に解消されることに。逆に言うとそれまで全く解消せず。

 3.冷却ファンの品質が激安品。これに限らず基本的にこのシリーズは部品の品質がよろしくないのだが、シリーズ最初の製品から一括して激安品質なのがこのファン。
 そもそも40mmファンというブツ自体、ある程度おカネをかけてSanAce等の有名メーカー品を買っても割と簡単に壊れてしまうのに、そこに激安品突っ込んだら・・・まぁそういうこと。当たりハズレが激しくて、当たりだとまぁそこそこ動いてくれるのだが、ハズレだとあっという間に壊れて騒音&ノイズ源に。

 なので、壊れたものは自前で交換していたり。ファン自体は汎用品で問題無いのだが、電源コネクタが通常使われない小型品なので、電源コネクタだけ旧ファンから切り取って再利用が必要。
 それと、実はこの安物ファン、壊れてなくとも電源ラインに漏れて来るノイズが地味に凄かったのよ。これに関しては自分は気休め程度にコンデンサ(=ノイズフィルター)を電源ラインに追加して対応。

 4.シリンダー鍵を押さえ部分が構造的にヤワい。プラのパーツに穴を開けて金属の塊なシリンダー鍵を取り付けていて、シリンダー鍵に回転方向の力がかかり続ける、という構造上、シリンダー鍵の押さえ部分のプラにより硬い金属が力をかけ続ける=プラが削れ&歪んでしまい、そのうち押さえが効かなくなってシリンダー鍵自体が回転してしまうようになる、ということ。

 とはいえ実はこの問題、当時の製品のシリンダー鍵が(現在の製品から比べると)随分と真っ当なものだったので、キー自体が壊れてまともに回らなくなるまではそもそもキーを回すのにそこまで力をかける必要がなく、特に問題にならなかったんですな。
 構造がそのまんまシリンダー鍵が超絶劣化した現在ではこのヤワさが大問題なのだけど。

 5.実はシリンダー鍵のキーは消耗品。使っているとだんだん板厚が減ってきて、更に削れてくると元々平らだったところが凸凹になり、こうなるとキーとして使えなくなるという。
 なので、ケージを複数買ったらキーが何個も手元に残るが、これは捨てちゃ駄目なヤツ、ということで。

 まぁこんなことで製品としてとても「完成していた」とは言えないが、Owltechの製品は更に完成度が低かったりしたので、まぁまぁ悪くないかなとか思ったりしていたワケですよ。

 ◇REX-SATA

 REX-DOCKをPATAケーブルをそのまんまSATAケーブルに付け替えたようなもの。同じく、HDDケースもPC側に装着するケージも全てプラ製。
 そしてバリエーションモデルとして、アクセスランプ付(全プラ製)のもの、ケースとケージの一部がアルミ製で且つアクセスランプ付のものに加え、ケースとケージの一部がアルミ製だがアクセスランプ無のものも登場。
 ちなみにこのアクセスランプ、SATA信号線から取れず、別途マザーボードやSATAカードのピンヘッダに配線が必要だったというなかなかアレな仕様。

 この世代はカタログ上3Gbps対応を謳っていたものの、実際には接点部の信号品質がイマイチだったようで初期の3Gbps対応HDD等では相性問題という名前の「要するに信号劣化でCRCエラー多発」が出まくったという。なので自分はこの時代はマザーボード側でSATA速度を1.5Gbpsの制限して使っていましたな。
 あ、今では3Gbpsで安定して使えまっせ。でもこれ明らかにHDDが新モデルになってHDD側が信号処理が上手くなかったからだわね。

 まぁとはいえこの世代では特に「劣化」は進んでおらず、プラ製で歪みまくるケージも一部アルミ製の製品だとかなり抑えられている(歪まない訳ではない)のも一緒、おかげで一部は手元で未だに現役という。但し冷却ファンについては自分(勝手に=非純正品)に交換しているものもあり。
 後述するようにこの後世代がどんどん新しくなる度に致命的な欠点が増えていくため、ある意味一番マシだった世代とも言える。

 ◇REX-SATA3(初代)

 全プラ製品は無くなり、アルミとプラの組み合わせ構造のみに。そして待望のアクセスランプが標準装備となったものの、冷却ファンの位置が移動してしまったため、初代REX-SATAのプラケースでは実質的に冷却不能になるというかなりアレな事態に。
 またアクセスランプもSATA信号線から取るようになったが、信号線をHDD側のSATA15ピンから取っているため、同じく初代REX-SATAのプラ&アルミケース(=現行製品の「6Gbps対応」アルミ製ケース以外)ではアクセスランプが点きっぱなしになってしまうことに。
 あと、6Gbps対応を謳うも一部のデバイスで6GbpsではSATAリンクが不安定になるという症状も発生。但しこの症状が出る原因はこの製品固有の問題ではなく、単にSATAケーブル上に接点が増えて信号品質が劣化するからであり。そういうデバイスでは安物SATAケーブルや長尺SATAケーブルでも同じ症状が出ていたので割と症状が分かり易かったですな。

 この世代で良かったのはモデルチェンジしたHDDケース。それまでのものより構造が単純化された「ただの箱」に近い形になった分、ケージに入れた時に「ガタつき」が殆ど無くなり、しっかりした装着感と安定感が。最初からこうしとけば良かったのに。
 ・・・なのだが、コレもまた加工精度が悪く、モノによって本体とフタがギチギチだったり緩々だったりというとこがね、もぅ・・・。

 一方でこの世代でそれ以前と比べて一気に劣化したのが「シリンダー鍵」。何を変えたのか知らないが、初代REX-SATA世代に比べて「圧倒的に回しづらい」モノに。ある意味この製品シリーズの生命線とも言える重要なパーツなのだが、あっさり駄目なことに。

 こんな有様なので、シリンダー鍵を押さえている「このシリーズ伝統的な構造上の弱点」部分にモロに力がかかるようになってしまい、初代の頃のような「シリンダー鍵自体が壊れて回らなくなる」よりもずっと早く、シリンダー鍵の押さえ部分のプラが削れ&歪んでしまい押さえが効かなくなるので「シリンダー鍵自体が回ってしまい鍵が出来なくなる」という壊れ方が続発するようになってしまったという。
 同時に、冷却ファンが逝ってしまう前にシリンダー鍵の押さえ部分が壊れてしまうので、冷却ファンが壊れてしまうことを逆説的に考慮しなくとも良くなりました、えぇ(ぉぃ。

 ・・・この時点で自分の感覚値としては「あかんコレ」。

 ◇REX-SATA3(現行)

 初代から構造や部品構成等は変わらない(シリンダー鍵の周りのヤワい構造は勿論そのまま)。但しケージ側の信号線にバッファが入るようになり、一部のデバイスで6GbpsでSATAリンクが不安定になる問題が解決。
 ・・・ここまでやるならそのバッファからアクセス信号貰えば良いのに、アクセスランプの信号線は相変わらずHDDから引っ張っているという。

 で、「構造や部品構成」は変わらないたのが、更に酷くなったのがまたしても「シリンダー鍵」。ある意味この製品シリーズの生命線とも言える重要なパーツ(繰り返し)の筈なのだが、「ほぼ全てが新品の時からまともに回らない」という更に凄まじい品質劣化っぷり。シリンダー鍵部分だけなら「歴代最低記録更新」と言ってしまって全く過言ではない。

 それでは「まともに回らない」の意味はというと、「何か引っかかっているようなトコを力で無理やり回すしかない」ということ。初代REX-SATAの頃のようにキーを差し込んだらするっと回る、というものは見たことが無く、品質のバラつきで「カチャッと妙な引っかかりがある」程度のものから「ぐいっと力入れて押し込まないと鍵が回らない」、更に酷いものになると「キーをまっすぐ差し込んでも動かないので斜めに力がかるようにしないと鍵が回らない」なんてものまで。

 また、恐らくこれはキーの造りが雑なのと関係すると思われるが、キーが少し消耗して薄い部分が出てきたりした途端に全く回せなくなるシリンダー鍵が続発する。消耗しかけた同じ鍵でREX-SATAのケージは全て鍵回せるのにREX-SATA3のケージはほぼ回せないって、これどう考えたって後者の方が「劣化」しているでしょ。しかもケージ自体REX-SATAの方が使用期間が長いので、メカ的なダメージという意味ではREX-SATAの方が行っている筈なのに。

 で、こんな部品の品質なので、前モデルより更に「このシリーズ伝統的な構造上の弱点」部分に力がかかるようになってしまい、結果的にシリンダー鍵自体が回ってしまうまでの時間=製品寿命が更に短くなっているという。

 ◇

 以上、こんな感じ。
 今回ついに壊れたREX-SATAのケージは、そもそも同時期導入製品の半分は既に壊れて引退しているんで、まぁ文句は言いませんわ。

 ・・・でもなぁ。REX-SATA3のケージ買うのはなぁ。
 こんなエントリ書いてしまうぐらいには、嬉しくないんだよなぁ。すぐ壊れるだろうし。

 とはいえ直近では無いと不便で仕方がないので、実際問題として買うしかない。のだけど。
 この「次」はどうするかな・・・やっぱりUSB3.0なHDDケースまとめ買いして入れ替えるかなぁ。

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

Share

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