Windows 7 のメイン ストリーム サポートが終了。注意すべきポイントについて

Windows 7 のメイン ストリーム サポートが2015 年 1 月 13 日 (米国時間) に終了したことがニュースになっています。

Yahoo!ニュース - 「Windows 7」、メインストリームサポートが終了 （CNET Japan）

ただメインストリームサポートが終了しても、延長サポート中はセキュリティパッチも提供されますし、マイクロソフトのプレミアサポート等有料サポートは引き続き受けられるため、システムの現場ではメインストリームサポートの終了はあまり意識されない場合が多いんですよね。

■メインストリームサポート終了時の一番のポイントは？

私が考えるメインストリームサポート終了一番のポイントは、その製品に不具合があった場合の対応についてです。

マイクロソフト製品がらみのシステムを使っている場合、そのサポートにマイクロソフトのプレミアサポートなどの有料サポートを使うことがあります。
例えばWindows 7を利用するシステムのトラブルの際にマイクロソフトのプレミアサポートに問い合わせ、その結果Windows 7の不具合がシステムトラブルの原因だったことがわかったとします。
メインストリームサポート期間中は問い合わせ費用は原則無料になりますが、メインストリームサポートが終了し延長サポート期間であれば、Windows 7の不具合がシステムトラブルの原因であったとしても問い合わせ費用は有料となってしまいます。

これをエンドユーザー等に説明すると、何でマイクロソフト製品の不具合のせいなのに客が費用を負担する必要があるのか…とよく言われますので注意して下さい。

2014 年8 月13日公開の問題の更新プログラムが家のPCにもインストールされてました

2014 年 8 月 13 日公開の更新プログラムを適用すると、Stop 0x50 エラーで起動しなくなる場合があるとのことで、結構問題になっていますね。

マイクロソフトのセキュリティチームのブログ

【リリース後に確認された問題】2014 年 8 月 13 日公開の更新プログラムの適用により問題が発生する場合がある - 日本のセキュリティチーム - Site Home - TechNet Blogs

によると、

1. 2982791 [MS14-045] カーネル モード ドライバーのセキュリティ更新プログラムについて (2014 年 8 月 12 日)
2. 2970228 Update to support the new currency symbol for the Russian ruble in Windows
3. 2975719 August 2014 update rollup for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2
4. 2975331 August 2014 update rollup for Windows RT, Windows 8, and Windows Server 2012

の4つの更新プログラムが問題とのこと。

■家のWindows 7 PCにも問題の更新プログラムが…

わたしのWindows7母艦PCを確認してみたところ

おもいっきり問題の更新プログラムがインストールされてました…。が、とりあえずわたしのPCでは起動時にSTOPエラーは発生しませんでした。

まあ流石にWindows Updateで自動更新されるプログラムについてはGDRである程度ちゃんとした試験が行われているはずですので、 多分特定の環境でのみSTOPエラーや異常終了が発生するんだろうと思います。

■とりあえずアンインストールしておきました

MSのブログでは上記更新プログラムがインストールされていた場合、問題が発生してなくてもアンインストールが推奨されてます。以下のとおりアンインストールしておきました。

 上記の更新プログラムは現在は配信停止されているとのことですので、現時点でインストールされていない場合、インストールされていてもアンインストールできればひとまず安心です。

■起動しなくなった際の対処策もMSブログにあり

なお起動しなくなった場合の対処策も上記MSブログにありましたので、困っている人は確認して下さい。

VBScriptフリーズ時にまず確認すべきポイント

VBScriptで記述したバッチ処理がフリーズするトラブルが発生することがあります。この際にまず確認すべきポイントを紹介したいと思います。

■WScript.ShellのExecメソッド標準出力バッファ4KBの罠

もしフリーズが発生するVBScript処理内に


Set WSHShell = CreateObject("WScript.Shell")
Set oExec = WSHShell.Exec("cscript scriptworker.vbs")

こんな感じで、Execメソッドを使っていれば、まず間違いなく標準出力（あるいはエラー出力）のバッファあふれによるフリーズの可能性大です。

Execメソッドでの標準出力及びエラー出力のバッファサイズが4KBのため、大量に処理結果が出力されるとバッファが一杯になり処理がブロックされてしまいます。

■解決策

マイクロソフトのサイトにあるとおり、

Hang When Reading StdErr/StdOut Properties of WshScriptExec Object








StdOut及びStdErrプロパティから標準出力結果を適宜読み出してあげればOKです。

■デッドロックが発生する可能性もあり

以下のブログ
へたれたプログラマの憂鬱 WSHのExecメソッド

によると、StdOut及びStdErrプロパティから標準出力結果を適宜読み出すだけでは、場合によってはデッドロックを引き起こす可能性もあるとのこと。

現場ではそのようなケースに遭遇したことはないですが、運悪くそのケースにハマった場合は標準出力をリダイレクトしてファイルに吐き出す等の対応が必要になります。

IE11だとセキュリティゾーンの違いのみで画面崩れが発生する可能性あり

マイクロソフトサポートチームのブログに、こんな記事が出ていました。

Internet Explorer 11 における文字列表示の変更点について


　概要はこんな感じです。

• IE9からナチュラルメトリックという画面のピクセル計算をより厳密に行う仕組みが導入された
• IE11よりナチュラルメトリックの適用範囲が大きく広がり、イントラネットゾーン以外では原則有効になる

 　ナチュラルメトリックというのはIE9では サブピクセルフォントと呼ばれていたもののようです。
IE9 のサブピクセル フォント - Internet Explorer ブログ (日本語版) - Site Home - MSDN Blogs


　要はナチュラルメトリックにより画面のレンダリングのロジックが変わるため、スタイルシートなどでピクセルを細かく指定している画面については、画面崩れが発生する可能性があるわけですが、IE11では、 セキュリティゾーンの違いのみでナチュラルメトリックによる画面崩れが発生する場合があるということになります。

　今までの常識だとドキュメントモードの違いで画面表示が崩れるというようなことはありましたが、今後はセキュリティゾーンの違いでも画面崩れが発生するケースも多くなると思われますので、注意して下さい。

　なお回避策として、metaタグ
 <meta http-equiv="X-UA-TextLayoutMetrics" content="gdi">
を入れることで、 ナチュラルメトリックが適用されなくなるとのことなので、とりあえずの回避策としてはこれが一番簡単そうです。