【警鐘】[改元][Windows][.NET] 「令和」対応パッチで画面が横に伸びる、文字が見切れる ― Windows Update 手動更新はちょっと待った方がいい

2019年4月29日 23:58

※2019年5月15日（日本時間）に自動配信が開始された修正版パッチで、フォント起因の横伸び、見切れ問題は解消されました。

---

4月26日、「令和」対応パッチが Windows Update で配信開始されました。
日本の元号の変更について - KB4469068

現状は手動更新（「更新プログラムのチェック」）または Microsoft Update カタログからのインストールのみで、自動更新への反映は来月半ば頃と見られています。
また、Windows 10 / Server Version 1809 向けのパッチは "Coming soon" となっており、配信予定が明らかではありません。
⇒ 5月2日、上記ページを確認すると、同日付で更新されており、Windows 10 / Server Version 1809 向けもリリースされていました！
2019 年 5 月 2 日 — KB4501835 (OS ビルド 17763.439)
（5月3日にはその他の累積的な修正を含む KB4495667 がリリースされました。一時誤って自動配信されましたので、何もしていないのに入っていた、という環境もあるはずです。そして一度手動適用した私の環境では、消しても消してもゾンビのようにまた降ってきます）

リリースの報に触れて「ようやく来た！」とインストールを急ぎたくなる気持ちはわかります。

が、ちょっと待ってください。

慎重になるべき理由

・プレビュー版である
・「令和」対応以外の変更も含まれている

プレビュー版である

今回配信されるのは月例更新プログラムの「D」リリースで、翌月の「B」リリースに向けたプレビュー版という位置づけです。

Windows の月例セキュリティ更新プログラムと品質更新プログラム - Windows Blog for Japan

目的は、翌月の「B」リリースに含まれるセキュリティ以外の修正を公開し、テストできるようにすることです

ここに至るまでのずんどこな経緯（※1）から、マイクロソフト社の改元対応が難航していることは明白です。

あえて全OS一斉の正式リリースをせず、古いOS向けのプレビュー版のみ、申し訳のように改元直前の営業日に滑り込ませた意味を考えましょう。

手動適用は開発や検証に必要な範囲にとどめ、運用環境ではなるべく正式リリースを待った方が無難です（※2）。
（それでも適用したい方は、せめてこの記事を最後まで読んでからにしましょう）

「令和」対応以外の変更も含まれている

新元号「令和」対応だけのリリースではありません。
月例更新プログラムの一部として提供されますので、関係のない変更も同時に適用されることになります。

変更内容は、たとえば Windows 10 Version 1803 向けの場合、『2019 年 4 月 26 日 — KB4493437 (OS ビルド 17134.753)』に列記されていますが、挙げられているのはあくまで「主要な」変更点であり、実際にはここに記載のない変更も含まれます。

破壊的変更／不具合

「元年」表記

『[.NET][改元] 「元年」表記に変わる日付書式が今になって拡大！（フレームワーク別の対策が必要）――マイクロソフト様、重大な変更をしれっとリリースしないで』で扱った問題です。

Windows 10 Version 1803 に今回のパッチをあてたところ、シングルクォーテーションなしの書式 "y年" で「元年」と出力される変更も適用されていることが確認できました。

Windows 8.1 では影響がないようで、今回のパッチをあてた後も、KB4488667 があたっていなければ "y年" で「1年」と出力されました。
さらに「元年」表記自体が導入された KB4459943 があたっていなければ、"y'年'" でも「元年」でなく「1年」と出力される結果となりました。

Windows 7 SP1, Windows 10 Version 1809（KB4501835 / KB4495667）にもこの変更は含まれていないようです。

いずれにしても、最終的には "y'年'" でも "y年" でも「元年」表記になる見込みですので、リンク先記事の問題を解消していない場合は対応を急いだ方がいいでしょう。

画面が横に伸びる

ここからが今回の主題です。

何が起こったのか？

AutoScaleMode が Font（Visual Studio の既定）の Windows フォームで、画面表示が横に伸びてしまう現象を確認しました。

AutoScaleMode が Font の場合、開発デザイン時のフォントサイズ（AutoScaleDimensions）と実行時のフォントサイズ（CurrentAutoScaleDimensions）の差異（AutoScaleFactor）を吸収すべく自動スケーリングされますが、このフォントサイズの測定結果が今回のパッチ適用前後で変わってしまったようです。

具体的な例として、MS UI Gothic（9pt）で以下のように横幅が 1px 大きくなり、結果としてコントロールの表示サイズが横に広がってしまいました。

[パッチ適用前] Width: 6.0／Height: 12.0
[パッチ適用前] Width: 7.0／Height: 12.0

実行時だけでなく、Visual Studio デザイン時の表示幅も自動スケーリングされ、横に伸びます。
何か変更して保存すると、AutoScaleDimensions プロパティのデザイン設定値が SizeF(6F, 12F) から SizeF(7F, 12F) に変わります。

何が困るのか？

特にフォームの幅を固定していない場合、想定したディスプレイ領域から画面がはみ出してしまう、という問題が考えられます。

フォームの幅を固定している場合は、中身の文字やコントロールだけが大きくなり、収まりきらずに見切れてしまう恐れがあります。
必要なものが見えなかったり入力できなかったりと、障害としてはこちらの方が深刻でしょう。

フォームを継承している場合、一部のコントロールのみが横伸びして画面や想定した表示域に収まりきらなくなる現象も確認されました。
この不整合自体は自動スケーリングにもともと存在する不備と考えられますが、今まで対象にならなかった（本来不要な）ケースで自動スケーリングが適用されることにより、問題が顕在化してしまいました。

なぜこんなことになってしまったのでしょう？

ContainerControl.CurrentAutoScaleDimensions プロパティは、AutoScaleMode が Font の場合、GetFontAutoScaleDimensions メソッドを呼び出します。

この ContainerControl.GetFontAutoScaleDimensions メソッドのソースコードを確認しますと、a-zA-Z の文字列の横幅を測って1文字当たりの値を整数に丸めるという、かなり危うい臭いのする処理になっていることがわかります。

確かに Microsoft Docs の説明

If the mode is Font, this property represents the average font character size in pixels.

に沿った実装とは言えますが、わずかなフォント幅の変化に対してリアクションが豪快すぎやしないでしょうか。

内部実装とは違う方法ですが、パッチ適用前後のテキスト幅を実際に計測してみました。

const string fontMeasureString = "abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ";
var font = new Font("MS UI Gothic", 9.0F);
var textSize = TextRenderer.MeasureText(fontMeasureString, font);

Console.WriteLine($"({textSize.Width}, {textSize.Height})");

MS UI Gothic／ＭＳＰゴシック：(343, 12) ⇒ (345, 12)
ＭＳゴシック：(317, 12) ⇒ (317, 12)
ＭＳＰ明朝：(344, 12) ⇒ (344, 12)
Arial：(368, 15) ⇒ (368, 15)
Yu Gothic UI：(352, 15) ⇒ (352, 15)
メイリオ：(388, 18) ⇒ (388, 18)
Meiryo UI：(387, 15) ⇒ (387, 15)

MS UI Gothic", "ＭＳＰゴシック" で、横幅がわずかに増えていることがわかりました。

.NET Framework の不具合というよりも、フォント周りの変更が想定外の形で影響を及ぼしてしまったのかもしれません。

リリース情報（たとえば Windows 10 Version 1803 向けの場合）には、フォント関連では

日本の新元号に対応するために、フォントを更新します。

日本の新元号のフォントの代替フォントを追加します。

という記載があるのみです。

後になって仕様変更と説明される可能性もありますが、唐突かつ目的が不明です。
事前のアナウンスなしにすべき変更ではないでしょう。
不具合ならば、正式リリース（自動配信）までに修正されることを強く望みます。

「D」リリースのプレビュー版的な位置づけからすると、「製品版と同じ品質の検証済みバージョン」とは謳われているものの、こうした障害も想定すべきなのかもしれません。
だとすれば、問題はむしろ、リスクを表に出さないリリースの仕方にあると言えるでしょう。
（それを補うべくこの記事を書いています）

なぜほとんど騒がれていないのでしょう？

不思議です。
単なる見た目のみならず、画面制御の仕方によっては致命的な障害になりうると思うのですが。
連休直前のリリースということもあり、あまり手動インストールはされていないのでしょうか。

一つ考えられるのは、特別な制御をしていなければフォームごと広がるので中身が収まりはする ⇒ ほんのり違和感を感じつつも気づかない可能性がある、ということです。

文字が見切れる／あふれて折り返される

Windows フォームのようにフォント幅に依存してコントロールの幅が伸びることがない場合、別の問題が発生してしまいます。

▼VB6（Visual Basic 6.0）
VB6 では、"ＭＳＰゴシック", "MS UI Gothic" でテキスト幅が増えてコントロール枠に収まらなくなる現象が確認されました。
TextWidth プロパティで a-zA-z の文字列の幅を計測すると、Windows 10 1809 など正常環境では 5070 twips のところが、Windows 10 1803 のパッチ適用後で 5100 twips とわずかに増えていました。
上の Windows フォームの実験でパッチ適用後にテキスト幅が変化しなかったフォントでは見切れが確認できませんでしたので、大元の原因は同じかもしれません。

▼Excel
日本語系フォントが軒並み大きく表示されてしまうという情報（スクリーンショット）があります。
私の環境では、"ＭＳＰゴシック", "MS UI Gothic" で、10.5pt のときテキスト幅が微増、11pt のとき微減という現象が出ました。

▼WPF（Windows Presentation Foundation）
影響なしと言い切るところまで検証はできていませんが、今のところ見切れの問題は確認できていません。

▼その他
Windows フォームほど深刻ではないとしても、影響は Windows 全体に及ぶ可能性がありそうです。

最悪「PCを初期状態に戻す」ことになる

KB4495667 に既知の不具合が追記されました。

After installing KB4493509, devices with some Asian language packs installed may receive the error, "0x800f0982 - PSFX_E_MATCHING_COMPONENT_NOT_FOUND."

いくつかのアジア言語パックがインストールされている場合にエラーが発生することがあるそうです。

If reinstalling the language pack does not mitigate the issue, reset your PC

言語パックをアンインストールしても解消しない場合はPCをリセットせよ、とあります。

対象のパッチは下記ページに列記されています。
Microsoft Confirms New Windows 10 Cumulative Update Issue, Recommends Full Reset

The full list of cumulative updates that come with the language pack glitch is the following:
April 9, 2019—KB4493509 (OS Build 17763.437)
May 1, 2019—KB4501835 (OS Build 17763.439)
May 3, 2019—KB4495667 (OS Build 17763.475)

ここにも記載されていますが、リセット（PCを初期状態に戻す）が最善策とは思えません。
パッチをアンインストールし、修正プログラムがリリースされるのを待った方がいいでしょう。

誤ってインストールして（されて）しまったら

誤配信もあったので、いつも間にか入っていた、ということもあると思います。

[プログラムと機能]-[インストールされた更新プログラム] から該当KBを選択してアンインストールすることができます。

続報

2019/05/08
Windows フォームの障害に関し、@tfukumori さんが報告してくださった Visual Studio の Developer Community で、エンジニアリングチームから「特定のフォントが原因とみて調査中」との回答がありました。
https://developercommunity.visualstudio.com/content/problem/555652/when-applying-the-cu-described-in-new-japanese-era.html

Thank you for reporting the problem. We are now investigating this issue because it is likely that the specific font is the cause. Please wait for the update.

2019/05/11
「MS UI Gothic」「ＭＳＰゴシック」でテキスト幅や列幅が変わってしまう Excel の障害が、既知の問題として追記されました。

When using the MS UI Gothic or MS PGothic fonts, the text, layout, or cell size may become narrower or wider than expected in Microsoft Excel. For example, the layout and cell size of Microsoft Excel sheets may change when using MS UI Gothic.

・Windows 10, version 1809 および Windows Server, version 1809
　May 3, 2019—KB4495667 (OS Build 17763.475)
・Windows 10, version 1803 および Windows Server, version 1803
　April 25, 2019—KB4493437 (OS Build 17134.753)
・Windows 8.1 および Windows Server 2012 R2
　April 25, 2019—KB4493443 (Preview of Monthly Rollup)

2019/05/15
本日（日本時間15日）リリースされた5月の Windows 月例更新プログラムで、「MS UI Gothic」「ＭＳＰゴシック」のフォント幅が修正され、それに起因する横伸び、見切れ問題が解消しました。

Visual Studio の Developer Community でも修正済みとの回答がありました。

The update we launched on May 15 includes a new version of msgothic.ttc that fixes this issue.
Future rollup updates will contain this fix cumulatively, so we recommend that you always apply the latest update.

以下は注意が必要な点です。（環境によって異なる場合があるかもしれません）

・KB4494441 は1回の更新では適用されないことがあります。（参考）
・KB4495667 がインストールされていなくても、KB4494441 のみで「令和」対応が適用されます。
・KB4495667 がインストールされている環境に KB4494441 をあてると、KB4495667 の不具合が修正されます。KB4495667 は [インストールされた更新プログラム] に出てこなくなります。
・同日配信の .NET Framework 累積更新プログラム KB4499405（.NET Framework 3.5/4.7.2 向け：KB4495590）に、シングルクォーテーションなしの書式 "y年" で「元年」と出力される変更が含まれています。（詳細）