やっちまった。

 TH2が公開されたので取り敢えず公開β程度の完成度にはなったのではないかという期待を持ってしまい、うっかりメインPCをWindows10にアップグレードしてしまいました。
 方法は・・・思いっきり手抜きの「アップグレード」。大体2時間弱ぐらいかかりましたかね。

 とはいっても「TH2で動かなくなった」ソフトもちらほら出ているので、万人にはお勧めしません。
 そういう自分も取り敢えず上げてはみたものの、普段使いのソフトが一つ使えなくなってしまい、さてどうしたものかという真っ最中なので。

 #最悪パーティションイメージから元に戻せる状態にはしてありますよ。

 ・・・つか、こういう互換性に関わる部分の重大な変更を告知無しで強行するなんて、Windows As A Serviceってそういう意味なんかね。
 そんなことするようじゃ、そもそもWindowsなんて・・・っととと、
 閑話休題、このネタは長くなりそうなので別エントリにします。

 #仕様変更でなくバグだよねきっと。まぁそれだって(以下略

 ということで、以下はあくまで参考情報ということで。
 実際にWin7からWin10へアップデートしてみたので、自分が一番ハマった点をメモっておきます。
 といいましてもネタとしては実に古典的な、定番の、使い古されたシロモノですが。

 ◇

 それでは、今回自分が痛い目を見た原因を。

 「カーネルに近い動作をするアプリはかなり危険、基本抜いておけ」
 「ドライバは7と8.1以降対応両対応のものがあれば最新版に、それが無ければ思い切って抜いておけ」

 ほら、よくある話でしょ?
 更に、TH2以降にする(なる)場合には、以下の項目も大事。

 「DigiOn製のDTCP-IPに関連するソフトはTH2でBSODの原因になるので確実に抜いておけ」

 これからIn-place Updateをしようという皆様、本当にコレ重要ですよ。

 当方のように、ランダムに頻発するBSODに脅されながら、一生懸命ドライバのUpdateしたり、疑わしいアプリのUninstallしたりするという、非常に非生産的且つ被虐的な時間を過ごしたくなければ。

 ♯以前ちょっと書いたように、当方メインPCでは結構色々な常駐モノ・組込モノを動かしていてのも原因の一つと思われる。

 特に当方のようにWindows7からの移行だと、Win8からの移行だと恐らく問題無いのだろうがWin7からの移行だとヤバい、という代物が結構ある模様。
 この原因はほぼ100%、ドライバのお作法がWin8から変わっていることなのですよ。
 Win8.1で動くドライバがWin10でコケる確率は高くないが、Win7となるとコケない確率の方が高くない。

 こういうブツが日和見BSOD(というか)の最大の原因なのだが。
 おっかないのは、この日和見BSODを起こす原因の中に、USBやGPU等の必須ドライバも(当然)含まれること。

 ♯前述したDigiOn製DTCP-IP関連ソフトもこの類。
  インストールするとDTCP用ドライバが裏で自動的に動き始めるのだが、こいつがCRITICAL_STRUCTURE_CORRUPTIONを日和見で吐いてくれる。
  ドライバの問題なので上物のアプリを起動しなくともインストールしてあるだけでBSODになるし、大体1時間も持たない。

 だったらそのテのドライバぐらいインストーラが事前に検出して警告してくれれば良いのに、とは思うのだが、そんなことに気を使ってくれないのはMSのいつものことなので。
 実際、当方では検証用環境をWin8.1から10に上げた方では特にBSODなんて発生しなかっのに、本番機のWin7からの(なんの事前準備もしていない)アップデートだとまぁBSODの嵐となったワケですよ。

 しかも、USB3.0等の「そもそもWindows10ではベンダドライバ不要」なんてブツでも、Win7用のドライバが存在すると、何故かこの古いドライバとWindows10用ドライバが衝突して、BSODだけでなくデバイス自体も正常に動かないなんて羽目に。

 なので、こういう困ったドライバ対策として、オススメなのは「一度全部抜いて、MS純正ドライバが当たっている状態にしてしまえ」ということ。
 この状態だと確実にUpdateプロセス中で更新されるので。

 そしてこの「事前準備」は確実にUpdate前に行うこと。
 Update後にはUninstallが正常に出来ないモノが・・・まだコレはまし。
 レジストリやらを直接修正するハメに・・・これでもまだマシ、起動出来ているんだから。

 最悪なのは、そのドライバのせいで自動修復すら起動出来なくなって、要するに「環境が死んで」しまうこと。
 起動時に必須ドライバとして読み込まれるブツにNGドライバが混ざっていると、最悪こういうことになるんですわ。
 ぁぅぁぅ。

 ♯なのでもう、開発系は出来るだけ触らずに一旦大掃除することにしました、はい。

 ◇

 とまぁこんな感じで、取り敢えず上げた時の雑感ということで。

 ・QuickLaunchは以前と同じ方法で復活可能。個人的にはコレ超重要。

 ・CtrlとCaps他、キーレイアウトのレジストリでの入替もそのまま使える(Updateの時消えるので要再導入)。個人的にコレも超重要。

 ・当方のように単色背景を使う人間にとっては、以下の2つのコマンドラインは必須。
  というかコレなんでGUIから削ったん。

  control /name Microsoft.Personalization /page pageWallpaper
  control /name Microsoft.Personalization /page pageColorization

 ・BSODを発生させないにしても、一度Uninstallした後再Installしないと正常動作しないアプリも少なくない。
  修復ではダメ、アレ?と思ったら取り敢えずUninstall&再Install。

 ・正常にUninstall&再Install出来ればアプリもドライバも意外と古いモノでも普通に動く模様。この辺りはさすがMSといったところか。

  但し「普通に動く」ことを確認するまではものすごく大変。
  ドライバ類だと前述した「日和見BSOD」起こすブツが正直言って少なくないし、アプリでもウィンドウやボタンが妙にズレて肝心なトコが押せなかったりなんてパターンも。

 ◇

 以上、S.KazのWindows10 In-place Updateドタバタ騒動記、若しくは「常駐モノや組込モノが多い人は御注意あれ」というお話でしたとさ。

 今回はこの辺りで。

Share

いやはや、何やってるのさ。

 さて今回のネタはMSの突然の暴挙から。
 よりにもよって、OneDriveの容量を「減らしますよ」と来たもんだ。

 このことが最初に発表されたOneDrive blogのコメント欄は見事に炎上したが、まぁソレが普通でしょうと。
 取り敢えず、今回の件でMSが得たもの

 1・ストレージの少しの空き容量
 2・Microsoftはユーザに不便や出費を強いるサービス変更を簡単に行うという実績
 3・Microsoftの製品に対する「漠然とした」不信感
 4・現在無料アップデート中のWindows10も突然サブスクリプションに強制移行するのではないかという「漠然とした」疑い

 自分の感覚ではコレどう考えたって割の合う話ではないと思うのだが、本当にMSは割が合うと思ってやっていたのだろうか。

 ◇

 まぁ既に色々なことがあちこちで言われているので、ここでは極めて冷静に分析してみましょうか。
 そうすると、こういう結論になるかと。

 「MicrosoftはOneDriveを魅力的な商品とする意思が無いことを明言した」

 Office365の1TBストレージセットはGoogleと見比べた際に見劣りしない為だけに付けているという解釈が十分成り立つ。
 有料プランに関してはもう単純に、「買ってくれるな」と言わんばかりの高値付。
 感情論を全部拭い去っても、スペックを見比べただけで明らかに見劣りする以上、OneDriveを選ぶ理由が見当たらないんですわね。

 ◇

 とはいえ、実際には人間の行動原理に感情が入らないなんてことはないワケですよ。
 そうすると、最初に書いたような実績を基に「漫然とした」不信感がと疑いを持ってしまった以上、今後のMicrosoft製品の個人への売上には少なくない影響があると思うのだが。

 ちなみに他社はというと、有名処は基本的にサービスそのものからの撤退以外でユーザーベネフィットのデグレードはやっていない。
 もちっと日本語分を多めにするならば「既得権益」を削っていない、とも言える。
 そうしてユーザーに「取り敢えずはまぁ使い続けられるのかなぁ」という「漠然とした」期待を持たせるワケですよ。

 勿論「漠然とした」というレベルであって、クラウドサービスなんてその程度のものなのだが、その「漫然とした」期待が無ければそもそもサービスを使おうなんて気にもならないし、増してや課金してなんて発想なんて出てこない。
 そして実際使ってもらうことで「実績」が出来て「信頼感」が生まれ、それが延々積み重なってやがて「信頼」となり、ロイヤリティの高い(継続使用してくれる、高額な商品を買ってくれる)顧客を生み出す大切な要素となる。

 そういう意味でもこの「漫然とした」期待を持ってもらうことは極めて重要なワケですよ、これはもうビジネスに限らずあらゆる場面で。
 この基本的なステップの最初にある「漠然とした」期待をMSはさっくり裏切ってしまったワケですわ。
 それって最悪の選択でないの?と。

 ◇

 しかもこの「既得権益を削った」相手が、圧倒的多数の無料ユーザだってのはもう。
 母数が多ければ確率論の世界で声が大きい(中にはクレーマーだって・・・)連中も少なくないワケで。
 こういう連中は基本的に「売上に貢献しないが全力で足は引っ張る」のよ?

 短期的なストレージ費用負担(長期的に見れば相対的に「薄まる」筈)と、このテの悪評流されるリスクを天秤にかけて、わざわざ後者を取ったってのは、正直自分には理解出来ませんわ。

 一方、有料ユーザにとっては精神的には大事ではないかというと、これまた全然そんなことはないのであり。

 そもそも容量無制限と言ったなら無制限で提供しろよ、というのが基本行動原理が契約である世界の常識。
 にも拘わらず「大量のデータをアップロードしているユーザが居る」ことを理由にサービス内容変更というのは、世界の常識からすれば言い訳にも何もならず、単に「契約不履行である」としか言いようがない。

 #契約という関係に疎い日本人にはこの辺りの欧米人の感覚はどうにも理解されていない気がする。

 なので当然、「MSは契約を一方的に反故にする企業である」という印象を持たれたワケですよ。
 有料ユーザにしたって「そりゃねーだろ」となりますわ、コレは。

 ◇

 にしても今回のネタ、サービス内容変更が相当刺激的なことは勿論だが、その発表方法があまりにも朴訥だったのも騒動に拍車をかけた原因だと思うのだが。

 これが仮に「データ総量が見込みを上回って増大し、サービス継続に支障が出かねないので」と言っていたら、もう少しだけ世間の反応は違ったとは思うのだが。BidCasaもHPも過去に「やらかして」いるので・・・同じくブーイングの嵐ではあっただろうが。

 ・・・つか、こんな騒ぎを起こすならそもそも「容量無制限です」などと言わなきゃ全て丸く収まっていたのだが。
 余計なこと言って余計なことして自爆した、というか、オウンゴールだとか、そういう展開でしょうコレは。

 まぁ実態としてはどうせ、容量無制限を打ち出した時と現在とではMS側の人も入れ替わっているんでしょう。
 「前任者が何言ったか知らないが自分はこうやるんで」というとてもビジネスライクな判断をしたんでしょうな。
 ところがユーザーはそんな短期間で入れ替わるワケがないし、ましてやMSの中の人間の入れ替わりなんて知ったこっちゃないという。

 ◇

 まぁこの後暫くの注目は、思わぬ長期的なビジネスチャンスを与えられてしまったクラウド系各社と、国内では思わぬ棚ぼたなNAS屋各社ではないかと。
 最近イケイケのQNAPとかはアキバでは売り上げ右肩上がりだそうだし、少なくとも国内のエンタープライズ系では「ファイルサーバ」の扱いが面倒臭くなってきた連中がアプライアンスである(=運用を含めたトータルコストでは結構下がることが期待出来る)NASへ移行するケースも増えてきているので。

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

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