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

※2019年5月15日（日本時間）に自動配信が開始された修正版パッチで、フォント起因の横伸び、見切れ問題は解消されました。（[2019/05/15 続報](#20190515) をご参照ください）

---

2019年4月26日、「令和」対応パッチが Windows Update で配信開始されました。
[日本の元号の変更について - KB4469068](https://support.microsoft.com/ja-jp/help/4469068/summary-of-new-japanese-era-updates-kb4469068)

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

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

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

# 慎重になるべき理由

## プレビュー版である

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

[Windows の月例セキュリティ更新プログラムと品質更新プログラム - Windows Blog for Japan](https://blogs.windows.com/japan/2019/04/11/windows-monthly-security-and-quality-updates-overview/)

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

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

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

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

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

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

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

# 破壊的変更／不具合

## 「元年」表記

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

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

Windows 8.1 では影響がないようで、今回のパッチをあてた後も、[KB4488667](https://support.microsoft.com/ja-jp/help/4488667/description-of-the-update-for-net-framework) があたっていなければ "y年" で「1年」と出力されました。
さらに「元年」表記自体が導入された [KB4459943](https://support.microsoft.com/ja-jp/help/4459943/description-of-the-security-and-quality-rollup-for-net-framework-4-5-2) があたっていなければ、"y'年'" でも「元年」でなく「1年」と出力される結果となりました。

Windows 7 SP1（@ht_deko さんの[検証結果](https://qiita.com/ht_deko/items/249db60e1c99ba440969#net)）, Windows 10 Version 1809（KB4501835 / KB4495667）にもこの変更は含まれていないようです。

いずれにしても、最終的には "y'年'" でも "y年" でも「元年」表記になる見込みですので、[リンク先記事](https://note.mu/codeone/n/n3e15ae03ac28)の問題を解消していない場合は対応を急いだ方がいいでしょう。

## 画面が横に伸びる

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

### 何か起こったのか？

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

`AutoScaleMode` が `Font` の場合、開発デザイン時のフォントサイズ（`AutoScaleDimensions`）と実行時のフォントサイズ（`CurrentAutoScaleDimensions`）の差異（`AutoScaleFactor`）を吸収すべく [自動スケーリング](https://docs.microsoft.com/ja-jp/dotnet/framework/winforms/automatic-scaling-in-windows-forms) されますが、このフォントサイズの測定結果が今回のパッチ適用前後で変わってしまったようです。

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

|      |Width|Height|
|------|-----|------|
|パッチ適用前|6.0|12.0|
|パッチ適用後|7.0|12.0|

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

### 何が困るのか？

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

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

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

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

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

この [`ContainerControl.GetFontAutoScaleDimensions` メソッドのソースコード](https://referencesource.microsoft.com/#System.Windows.Forms/winforms/Managed/System/WinForms/ContainerControl.cs,71c9f1e4ec45150b) を確認しますと、a-zA-Z の文字列の横幅を測って1文字当たりの値を整数に丸めるという、かなり危うい臭いのする処理になっていることがわかります。

確かに [Microsoft Docs の `ContainerControl.CurrentAutoScaleDimensions` プロパティ](https://docs.microsoft.com/en-us/dotnet/api/system.windows.forms.containercontrol.currentautoscaledimensions?view=netframework-4.8) の説明

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

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

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

```c#
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<br />ＭＳ Ｐゴシック|ＭＳ ゴシック|ＭＳ Ｐ明朝|Arial|Yu Gothic UI<br />(Windows 10 v1803)|メイリオ|Meiryo UI|
|------|-----|------|------|------|------|------|------|
|パッチ適用前|(34<font color="red">3</font>, 12)|(317, 12)|(344, 12)|(368, 15)|(352, 15)|(388, 18)|(387, 15)|
|パッチ適用後|(34<font color="red">5</font>, 12)|(317, 12)|(344, 12)|(368, 15)|(352, 15)|(388, 18)|(387, 15)|

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

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

リリース情報（[たとえば Windows 10 Version 1803 向けの場合](https://support.microsoft.com/ja-jp/help/4493437)）には、フォント関連では

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

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

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

「D」リリースのプレビュー版的な位置づけからすると、「[製品版と同じ品質の検証済みバージョン](https://blogs.windows.com/japan/2019/04/11/windows-monthly-security-and-quality-updates-overview/)」とは謳われているものの、こうした障害も想定すべきなのかもしれません。
だとすれば、問題はむしろ、リスクを表に出さないリリースの仕方にあると言えるでしょう。
（それを補うべくこの記事を書いています）

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

（2019/04/29 時点）

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

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

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

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

### Windows フォーム（.NET）

Windows フォームでは、自動スケーリングに関連した上記「画面が横に伸びる」の問題がありましたが、こちらの問題が発生することもあります。

たとえば、ボタン幅ぎりぎりにテキストを収めている箇所で、文字が見切れる問題を確認しました。

### VB6（Visual Basic 6.0）

VB6 では、"ＭＳ Ｐゴシック", "MS UI Gothic" でテキスト幅が増えてコントロール枠に収まらなくなる現象が確認されました。
（@maketa さんに検証結果をコメントいただいたとおりです）

TextWidth プロパティで a-zA-z の文字列の幅を計測すると、パッチ適用前の環境では 5070 twips のところが、Windows 10 1803 のパッチ適用後で 5100 twips とわずかに増えていました。
上の Windows フォームの実験でパッチ適用後にテキスト幅が変化しなかったフォントでは見切れが確認できませんでしたので、大元の原因は同じかもしれません。

### Excel

@HARUMARISENA さんや @maketa さんのコメントで、Excel でも見切れやレイアウト崩れが発生するという情報をいただきました。

@HARUMARISENA さんの環境では Excel 2016 で日本語系フォントが軒並み大きく表示されてしまったようで、スクリーンショットをつけてくださいました。

@tfukumori さんも[スクリーンショット付きで検証結果を公開](https://qiita.com/tfukumori/items/a1fb3984a3488875515e#56%E8%BF%BD%E8%A8%98excel-2013)してくださいました。

私の環境では少し現象が異なり、Windows 10 Version 1809 に KB4495667 をあてる前後の Excel 2019 で以下のような違いが出ました。

|      |MS UI Gothic<br />ＭＳ Ｐゴシック|ＭＳ ゴシック|ＭＳ Ｐ明朝|ＭＳ 明朝|Meiryo UI|
|------|-----|------|------|------|------|
|9pt|変化なし|変化なし|変化なし|変化なし|変化なし|
|10.5pt|<font color="red">テキスト幅微増</font>|変化なし|変化なし|変化なし|変化なし|
|11pt|<font color="red">テキスト幅微減</font>|変化なし|変化なし|変化なし|変化なし|
|12pt|変化なし|変化なし|変化なし|変化なし|変化なし|

11pt の微減は[山市良さんの確認された結果](https://yamanxworld.blogspot.com/2019/05/windows-update-2019-5-2-5-ver-1809-4-d.html)と同じ感じです。

@maketa さんのコメントや [@tfukumori さんの記事](https://qiita.com/tfukumori/items/a1fb3984a3488875515e#56%E8%BF%BD%E8%A8%98excel-2013) にある列幅が縮まる現象も、あるブックで確認できました。
そのブック内のシートを別の問題の発生しないブックにコピーした場合は無事だったりと、発生条件は特定できていません。

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

### その他

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

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

[KB4495667](https://support.microsoft.com/ja-jp/help/4495667/windows-10-update-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](https://news.softpedia.com/news/microsoft-confirms-new-windows-10-cumulative-update-issue-recommends-full-reset-525880.shtml)

> 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を初期状態に戻す）が最善策とは思えません。
パッチをアンインストールし、修正プログラムがリリースされるのを待った方がいいでしょう。

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

[誤配信](https://forest.watch.impress.co.jp/docs/news/1183014.html)もあったので、いつも間にか入っていた、ということもあると思います。

[プログラムと機能]-[インストールされた更新プログラム] から該当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<br />[May 3, 2019—KB4495667 (OS Build 17763.475)](https://support.microsoft.com/en-us/help/4495667)

- Windows 10, version 1803 および Windows Server, version 1803<br />[April 25, 2019—KB4493437 (OS Build 17134.753)](https://support.microsoft.com/en-us/help/4493437)

- Windows 8.1 および Windows Server 2012 R2<br />[April 25, 2019—KB4493443 (Preview of Monthly Rollup)](https://support.microsoft.com/en-us/help/4493443)

### 2019/05/15

本日（日本時間15日）リリースされた[5月の Windows 月例更新プログラム](https://portal.msrc.microsoft.com/ja-jp/security-guidance/releasenotedetail/e5989c8b-7046-e911-a98e-000d3a33a34d)で、「MS UI Gothic」「ＭＳ Ｐゴシック」のフォント幅が修正され、それに起因する横伸び、見切れ問題が解消しました。

Visual Studio の [Developer Community](https://developercommunity.visualstudio.com/content/problem/555652/when-applying-the-cu-described-in-new-japanese-era.html) でも修正済みとの回答がありました。

> 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.

報告してくださった @tfukumori さん、短期間で対応してくださったマイクロソフト社エンジニアリングチームの方々、ありがとうございました。
（感謝を込めて Solution にも vote）

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

- KB4494441 は1回の更新では適用されないことがあります。（[参考](https://yamanxworld.blogspot.com/2019/05/windows-update-2019-5-16-b.html)）
- KB4495667 がインストールされていなくても、KB4494441 のみで「令和」対応が適用されます。
- KB4495667 がインストールされている環境に KB4494441 をあてると、KB4495667 の不具合が修正されます。KB4495667 は [インストールされた更新プログラム] に出てこなくなります。
- 同日配信の .NET Framework 累積更新プログラム [KB4499405](https://support.microsoft.com/ja-jp/help/4499405/may-14-2019-kb4499405-cumulative-update-for-net-framework-3-5-4-7-2-an)（.NET Framework 3.5/4.7.2 向け：[KB4495590](https://support.microsoft.com/ja-jp/help/4495590/may-14-2019-kb4495590-cumulative-update-for-net-framework)）に、シングルクォーテーションなしの書式 "y年" で「元年」と出力される変更が含まれています。（[詳細](https://qiita.com/CodeOne/items/97c5a84cfa7376cbb629#20190515-%E8%BF%BD%E8%A8%98)）

# 関連情報

#### [2019/4/26のWindows 新元号（令和）対応パッチでのフォント変更？に関する調査（Windows 7, 10 1803） - Qiita](https://qiita.com/tfukumori/items/a1fb3984a3488875515e)

@tfukumori さんがOS環境別の VB6 / .NET 検証結果をスクリーンショット付きで公開されています。

[^1]: たとえば以下のようなことがありました。

 - [弊社製品の新元号対応予定について – Japan New Era Name Support Blog](https://blogs.technet.microsoft.com/jperablog/2018/07/20/microsoft-products-newera-schedule/)（2018/07/20）
 > 本 blog の以前の記事では、6 月を目途に上記の情報を公開する予定であるとお伝えしておりましたが、現時点では引き続き詳細な検証が必要な状況と判断しており、個々の製品やバージョンでの動作や新元号への対応方法等について明確にお伝えするに至っていない状況でございます。

 - [日本国の新しい元号は「？？」です→やっぱりやめました - Qiita](https://qiita.com/jTakasuRyuji/items/0e8eb484122734784ca2)

 - [マイクロソフトさん、お願いですから.NET Frameworkの動作を何の説明もなく変更するのはやめてください。- 改元対応で思うこと - Qiita](https://qiita.com/gushwell/items/88411bb2c833e7d7ff6b)

 - [2019 年 5 月の新元号への変更に関する更新](https://support.microsoft.com/ja-jp/help/4470918/updates-for-may-2019-japan-era-change)
 > 2019 年 4 月 1 日に新元号の名称が発表されました。弊社のエンジニアリング チームは、段階的に実稼働環境用の更新プログラムをリリースしていきます。完了するまでに数か月程度かかることがあります。

 - [Windows 10ミニTips(367) 「令和」前にチェック! 和暦を設定する方法 | マイナビニュース](https://news.mynavi.jp/article/win10tips-367/)（2019/04/12）
 > 先日筆者が日本マイクロソフトのセミナーに参加した際に知ったのだが、Windows 10でもハードコードが各所に残っているという。

 - [【令和】Microsoft の元号対応が迷走している件 - Qiita](https://qiita.com/ht_deko/items/249db60e1c99ba440969)
 奇しくも略して「MS」とは皮肉な。

 - [VB6、およびOffice VBAの元号対応の状況について - Qiita](https://qiita.com/tfukumori/items/aa9179f961eca86f192f)
 > パッチによっては、CDate、DateValueは強制終了する、という状況となる。
 > 
 > 元年表記についてもレジストリを参照して動作しない不具合があった。

 - [[.NET][改元] 「元年」表記に変わる日付書式が今になって拡大！（フレームワーク別の対策が必要）――マイクロソフト様、重大な変更をしれっとリリースしないで - Qiita](https://qiita.com/CodeOne/items/97c5a84cfa7376cbb629)

[^2]: 『[山市良のえぬなんとかわーるど: 本日の Windows Update － 2019 年 4 月 26 日（D リリース、令和付き）](https://yamanxworld.blogspot.com/2019/04/windows-update-2019-4-26-d.html)』でも、「（私は警告しましたよ）」としつこいくらいに注意喚起されています。