Windows 10 で PSR (Problem Steps Recorder)が動かない

そうなんです。
動かないのです。(v1703 で非推奨ツールに格下げされた)
PSR とコマンド入力しても、うんともすんとも動きません。
でも、PSR.EXE はきちんとあります。
Microsoft もあれだけ、宣伝して使ってくださいってアナウンスしていたのに…。

でも、動かせますので、その方法を紹介します。非推奨ということを認識した上で使ってください

方法

  1. ローカルポリシーエディター(gpedit.msc)を起動します。
    ローカルポリシー1
  2. 管理テンプレート – Windows コンポーネント – アプリケーションの互換性 まで辿ります。
    ローカルポリシー2
  3. ここに [ステップ記録ツールをオフにする] という項目がありますので、これを [無効] の設定にします。
    ローカルポリシー_PSR
  4. ポリシーを変更したので、お約束の gpupdate /force を実行しましょう。
  5. で、再度、PSR を実行してみると、動きます。
    Win10_psr

何とも、人騒がせです。
サポートしていると、結構、便利で使うんですけどねぇ。

Microsoft Message Analyzer が消えた

残念ですが、2019/11/25 付けでリタイヤだそうです。
いきなり来ましたね。
さて、netsh でキャプチャーしたネットワークトレース etl をどうやってデコードするか。

ダウンロード用のリンクも消えました。
後継製品 / ツールは無しで、WireShark を薦めています。
あらら…。

追記
etl を pcap に変換するのってそこまで大変じゃなさそう。
ググると、結構ありますね。
で、使ってみて良さそうなのは、MS の中の人が作ってくれたものかな。

Windows 10 の新元号対応 – 続続報

さらに続報です。Windows 10 1809 用の累積更新プログラムがリリースされました。

これで Windows 10 の新元号対応用の累積更新プログラムが出揃いました。
他の OS 用のロールアップもまとめておきましょう。

何も問題がなければよいのですが。

Windows 10 の新元号対応 – 続報

待ちわびた新元号対応の累積更新プログラムがリリースされました。

思いつく確認ポイントを書いておきます。

  • レジストリを確認
    前回記事で和暦に関するレジストリに触れましたが、今回の累積更新プログラムをインストールする前に
    可能であれば、"2019 05 01" = "令和_令_Reiwa_R" を削除して、累積更新プログラムがきちんとレジストリに
    追加することを確認した方がいいかも。

新元号_レジストリ_更新

  • フォントを確認
    新元号対応で予定されていたフォントが更新されていますね。
    MS ゴシック / MS 明朝 / MS P ゴシック / MS P 明朝 / メイリオ / Meiryo UI
    游ゴシック / 游明朝 / Yu Gothic / UD デジタル教科書体 / BIZ UDP ゴシック / BIZ UDP 明朝

新元号_フォント_更新

IMEパッドで合字令和を確認

さて、累積更新プログラムを適用して、気が付いてしまったことがあります。

累積更新プログラムの適用前

(条件)2019/04 までの累積更新プログラムは適用済 and レジストリで新元号対応しておく

新元号対応含む累積更新適用前

累積更新プログラムの適用後

新元号対応含む累積更新適用後

なんか、累積更新プログラムの適用前の方が期待した動きだと思うのですが。

  • Addresses an issue that causes the DateTimePicker to display the date incorrectly in the Japanese date format. For more information, see KB4469068.
  • Addresses an issue that causes the Date and Time Settings control to cache old Eras and prevents the control from refreshing when the time enters the new Japanese Era. For more information, see KB4469068.
  • Addresses an issue that causes the Clock and Calendar flyout control to display the day of the week incorrectly mapped to a date in the month of the new Japanese Era. For more information, see KB4469068.

このどれかの修正の影響ではないかと。
今更になって、累積更新プログラムの適用前後で動作が変わるのって勘弁してほしいですね。
ただ、この理由ですが、「令和」に改元されるのは、5月1日なので、その前に令和を使うのは、ダメ。(公的文書も同様)
そのため、現在時刻 / 日付 が 5月1日前なのか、後なのかで、表示を切り替えていると解釈できます。
そういう情報も書いておいてほしいですよね。
アプリ屋さん、かわいそうすぎる。

Windows 10 の新元号対応

平成も残り、カウントダウン状態。
ここで、Microsoft の新元号対応をおさらい。(情報源は今まで参加した Microsoft の新元号対応セミナーです)

  • 2019 年 5 月 1 日時点で延長サポートを終了していない製品
  • 現時点で和暦に対応している製品
  • Unicode のみ対応し、S-JIS は対応しない(合字)
  • 新元号対応のみを目的とした 更新プログラムの提供はなく、累積更新プログラムのみで提供される

これを踏まえて、Windows 10 の新元号対応をまとめてみましょう。

Windows 10 のバージョン Home / Pro / Pro for WS の
サービス終了日
Enterprise / Education の
サービス終了日
1809 2020 年 5 月 12 日 2021 年 5 月 11 日
1803 2019 年 11 月 12 日 2020 年 11 月 10 日
1709 2019 年 4 月 9 日 2020 年 4 月 14 日
1703 2018 年 10 月 9 日 2019 年 10 月 8 日
1607 2018 年 4 月 10 日 2019 年 4 月 9 日
1511 2017 年 10 月 10 日 2017 年 10 月 10 日
1507 2017 年 5 月 9 日 2017 年 5 月 9 日
  • LTSB / LTSC はサービス終了になっていたいため、すべて新元号対応する。
  • Windows Server 2016 / 2019 は対応するが、Windows Server バージョン 1709 (半期チャネル) は未対応になる
    (2019/04/09 切れ)。

この表からもわかるように Home / Pro / Pro for WS の新元号対応は、1803 以降が対象となり、
Enterprise / Education は 1703 以降が対象になります。 ここで重要なのは、フォント含めた完全な新元号対応ってことです。 例えば、Pro / 1709 は、3 月、4 月に累積更新プログラムがリリースされていますが、2019 年 4 月 9 日にサービス終了となるため、フォント含めた最終版の累積更新プログラムは提供されないってことです。

例えば、Pro / 1709 (サービスが終了している)に Ent / 1709 の累積更新プログラムを適用するのはいけません。Microsoft はそのような行為を認めていませんし、サポートも受けられません。

そのため、Home / Pro / Pro for WS の 1709 以前のバージョンを使っている場合、新元号対応するには、まずは、1803 以降にバージョンアップする必要があります。
そもそも、なんで、フォントの話しになったかというと、和暦には、合字 というものがあるからなんです。

IMEパッド合字を確認

この 合字 を入れたフォントも新言語対応としてリリースする必要があります。

現時点での新元号対応予定フォント
MS ゴシック / MS 明朝 / MS P ゴシック / MS P 明朝 / メイリオ / Meiryo UI
游ゴシック / 游明朝 / Yu Gothic / UD デジタル教科書体 / BIZ UDP ゴシック / BIZ UDP 明朝

Unicode における新元号の合字の符号位置は、2018 年の夏頃から申請を初めたらしく、2018 年 11 月あたりに U+32FF で確定したとのことです。そして、U+32FF で確定しても ICU や CLDR とかで制定する必要があるので、これまた、かなりの時間を要することに…。
新元号の符号位置が、明治 / 大正 / 昭和 / 平成 からかなり飛ぶので、和暦の照合順序の実装は大変ですね。
符号位置が決まっても肝心な 元号 が決まっていないので、2019 年 4 月 1 日の発表まで待ち状態。長いですねぇ。
なお、令和が入った ICU 64.2 は 2019 年 4 月 17 日に、Unicode 12.1 は 2019 年 5 月 7 日が制定日 / 公開日になります。

縦書きグリフ
フォントが横書き合字と縦書き合字を持っているかどうか。
縦書き合字を持っていない場合には、レンダリングエンジンで回転させるのですが、その際、近似フォントにフォールバックすることもあります(デザインが変わる)。

Unicode のみの対応ってことになるのですが、文字コード対応については

  • Microsoft による独自拡張は行わない
  • Code Page 932 / 拡張文字を含む S-JIS における新言語対応は行わない
  • ISO-10646 / Unicode 標準の対応に準じた更新を行う

ということになりますので、S-JIS はやらないよと。

第一世代 S-JIS
: JIS78 or JIS83 + メーカー拡張 [ ㍾ ㍽ ㍼ ]が含まれている
: [ ㍻ ] は、JIS X 0208 JIS X 0212 には含まれない
第二世代 S-JIS
: 第一世代では互換性 / 相互運用が担保されないために、Microsoft が各メーカーと調整して
   マイクソロフト標準キャラクタセット (Windows-31J / Code Page 932) を作成 (JIS90、10646)

ちなみに、IME 辞書にも更新が入るらしいです。
A) Win 7 SP1 まで
B) Win 8 – Win 10 1803
C) Win 10 1809
A – C は辞書フォーマットが異なり、互換性が無い!

あらゆるところで、和暦に関するレジストリが公開されているので、今更感ありますが、一応、紹介。

新元号_レジストリ

[ HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Nls\Calendars\Japanese\Eras ]
"1868 01 01" = "明治_明_Meiji_M"
"1912 07 30" = "大正_大_Taisho_T"
"1926 12 25" = "昭和_昭_Showa_S"
"1989 01 08" = "平成_平_Heisei_H"
"2019 05 01" = "令和_令_Reiwa_R"

なお、Windows OS、Office、.NET Framework 共に依存関係があるため、すべて最新に揃える必要があります。
Windows : KB4469068
Office  : KB4478844
.Net    : KB4477957

ちなみに、Windows 10 Version 1809 から、.Net Framework の累積更新プログラムは外出しされていますので、注意です。
平成 31 年 4 月末までに新元号対応を終了させたいとアナウンスされているので、そろそろ、フォント含めた累積更新が出てくるのではないでしょうか。

SQL Server に関して
SQL Server に対する新元号更新プログラムはないとのこと。(データベース機能には影響がない)
ただし、SQL Server 内部で .Net Framework を使っている機能は影響を受ける。
ストアドプロシージャや SQL CLR、SSRS、SSIS 等。
そのため、OS および .Net の新元号対応が必要になるため、結局、更新プログラムの適用が必要。
(特に SQL Server に接続するクライアントアプリは注意が必要)

OSの和暦表示

新元号への対応について
https://www.microsoft.com/ja-jp/mscorp/newera/default.aspx

2019 年 5 月の日本の元号変更に関する更新プログラム
https://support.microsoft.com/ja-jp/help/4470918/updates-for-may-2019-japan-era-change

Windows 用の日本の新元号対応更新プログラムについて – KB4469068
https://support.microsoft.com/ja-jp/help/4469068/summary-of-new-japanese-era-updates-kb4469068

.NET Framework 用の日本の新元号対応更新プログラムの概要
https://support.microsoft.com/ja-jp/help/4477957/new-japanese-era-updates-for-net-framework

日本の新元号に関する Office の更新プログラム
https://support.microsoft.com/ja-jp/help/4478844/office-updates-for-new-japanese-era

[経済産業省] 改元に伴う企業等の情報システム改修等への対応
https://www.meti.go.jp/policy/it_policy/kaigen/kaigen_taiou.html

Hyper-V 統合サービスの「ゲストサービス」

Hyper-V の統合サービスを見ると

Hyper-V_統合サービス

となりますが、ここの「ゲストサービス」って何?というのが今回ネタです。

を見ると、

Hyper-V ホストが仮想マシンとの間で双方向のファイル コピーを実行できるようにするためのインターフェイスを提供します。

とのこと。既定で無効なんですね。サービスコントロールマネージャーで見てみると

Hyper-V_統合サービスのサービス

ありました。
Copy-VMFile を使って、ホストマシンと仮想マシンとの間でファイルのコピーができるわけです。
使い方ですが、ホストマシン上の E:\Dotnet\ADO.NET\PoolingApp\Release\PoolingApp.exe.config というファイルを
仮想マシン “PC1 – Win10” の D:\work にコピーする場合は、こんな感じです。

Copy-VMFile "PC1 – Win10" -SourcePath "E:\Dotnet\ADO.NET\PoolingApp\Release\PoolingApp.exe.config" -DestinationPath "D:\work" -FileSource Host

注意点ですが、PowerShell を管理者権限で起動しておかないと、アクセス権が無い というエラーになります。

エクスプローラー上から GUI でファイル操作できると便利だと思うけどな。

Bootable USB メディアを作ろう

Windows 10 Anivasary Update 1607 が公開されました。
ワタシの環境は、Windows 10 Enterprise なので、Windows 10 更新アシスタントからの更新や
メディア作成ツールが使えません…。悲しい。

そうなると、自前で Bootable USB を作ることになるわけ(わざわざ、DVD に焼くのが勿体無い)で
忘れないように残しておきます。やることは 3 つのステップです。

  1. USB メディアのフォーマットとアクティブ化
  2. インストールメディアファイルの全コピー
  3. ブートセクタの書き込み

まずは、「USB メディアのフォーマットとアクティブ化」を Diskpart コマンドを使ってやります。

管理者権限でコマンドプロンプトを開く
Diskpart コマンド実行
DISKPART> list disk
DISKPART> select disk X (USB メディアのディスク番号)
DISKPART> clean
DISKPART> create partition primary
DISKPART> select partition 1
DISKPART> active
DISKPART> format fs=fat32
DISKPART> assign
DISKPART> exit

続いて、持っている ISO イメージをマウントして、「インストールメディアファイルの全コピー」を xcopy で
全てコピーします。

マウントした ISO ドライブを S: ドライブ、USB メモリを U: ドライブとする
XCOPY S:\*.* /S /E /F U:\

最後に「ブートセクタの書き込み」です。これはインストールメディアにある bootsect コマンドを使います。

マウントした ISO ドライブを S: ドライブ、USB メモリを U: ドライブとする
管理者権限でコマンドプロンプトを開く
S:\boot> bootsect /nt60 U:\

これでおしまい。

LDR と GDR

よく聞かれるので、まとめておこうと思う。

Microsoft は製品に何らかの不具合が見つかった場合に修正プログラムを提供しているのですが、この修正プログラムには

  • LDR : Limited Distribution Release
  • GDR : General Distribution Release

の二種類が存在します。
LDR も GDR も特定の問題に対する修正を行ったモジュールなのですが、LDR は局所的にテストを行ったもので、GDR は広範囲にテストを行ったものと認識してください。そのため、提供方法も若干異なります。
LDR はサポート技術情報(KB)からの個別ダウンロード & インストールとなるのですが、
GDR は、それに加えて、「重要な更新プログラム」という位置づけになると Microsoft Update でダウンロードされインストール
されることもあります。

  • 重要な更新プログラム
  • 更新プログラム
  • 更新プログラムのロールアップ
  • セキュリティ更新プログラム

よく、QFE という言葉を耳にしますが、本来、QFE(Quick Fix Engineering)は LDR のこと指しています。
なお、完全に特定環境における個別問題に対する修正モジュールを Hotfix と呼んでいます。

LDR に関しては一つ注意しておかなければならないことがあります。
一度でも LDR でモジュール適応した後、何かのタイミングで、そのモジュールがさらに更新されたとしても
LDR モジュールが適応され続けます。
更新されたモジュールに新しい LDR があれば、その新しい LDR が適応されることになります。
つまり、GDR が適応されることはなく、GDR を適応させたいという場合には、LDR をアンインストールした後に
GDR を適応する必要があります。

こんな事情があるので、Windows Vista 以降の GDR には、LDR が含まれています。
GDR は大体、拡張子 .msu (MIcrosoft Update Standalone Package)で提供されているのですが、
実は、このファイル展開することができます!

では、GDR の中にある LDR のインストール方法を紹介します。

  1. msu ファイルを個別に KB サイトからダウンロードする
  2. 適当なワークフォルダーを作成する
  3. コマンドプロンプトを開く(管理者用コマンドプロンプトである必要はない)
  4. コマンドプロンプトで
    expand -F:* <msuファイル名> <作成したワークフォルダー>
    を実行すると、ワークフォルダーにファイルが展開されます。
  5. ワークフォルダーに展開されたファイルの中に キャビネットファイル(.cab)がありますので、それを展開します。
    コマンドプロンプトで
    expand -F:* <cabファイル名> <作成したワークフォルダー>
    を実行すると、ワークフォルダーにファイルが展開されます。
  6. cab ファイルを展開したワークフォルダーに update-bf.mum というファイルがあることを確認します。
    これをパッケージマネージャーを使ってインストールします。
    pkgmgr /ip /m:<your dir>update-bf.mum

なお、ファイルのバージョン情報を見ると、LDR と GDR の区別ができます。

Win10: OS のバージョン

Windows 10 RTM が目前に迫ってきました。
常に付きまとうバージョン問題。ここらで、一度、Windows 10 のバージョン値を確認しておこうと思います。
バージョン番号を取得する際、お約束の GetVersion() と GetVersionEx() になりますが、実は
Windows 8.1 以降では、GetVersion() および GetVersionEx() は推奨されない API になっていて
versionhelpers.h で定義されている Version Helper 関数を使うように推奨されています。
ただ、Version Helper 関数だと、具体的なメジャーバージョン、マイナーバージョンの値を取ることができず
Windows 10 以降とか、Windows 7 以降とか、そういう判定しかできない。
おそらく、Microsoft としては、もうメジャーバージョンとかマイナーバージョンで判断するのは辞めれって
メッセージなのでしょう。
実際、Windows 10 以降、OS メジャーアップグーレードの概念を変えるとアナウンスされていますし。

MSDN によると、OS のバージョン番号を取るにはシステム DLL に対して、GetFileVersionInfo() で見なさいと
言っているので、ちと面倒だ。DllGetVersion() という API ものがあるのですが、これは Shell 系の API なので
サービスからは使えないので、やはり、GetFileVersionInfo() を使うことになるのか。

試したところ、Windows 10 でも、まだ、GetVersionEx() が使えるようなので、こっちを使ってバージョン値を
調べてみますが、いつ何時消えるかもしれないので、製品開発では使わない方がいいと思います。

OSVERSIONINFOEX osvi;
BOOL bOsVersionInfoEx;

// OSVERSIONINFOEX構造体を用いて、GetVersionEx()を呼び出してみる
ZeroMemory(&osvi, sizeof(OSVERSIONINFOEX));
osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFOEX);

bOsVersionInfoEx = GetVersionEx((OSVERSIONINFO *)&osvi);
if (!bOsVersionInfoEx)
{
    osvi.dwOSVersionInfoSize = sizeof (OSVERSIONINFO);
    if (!GetVersionEx((OSVERSIONINFO *)&osvi))
    {
        return GetLastError();
    }
}

Windows 8.1 / Windows Server 2012 R2 では、アプリケーションマニフェストの SupportedOS で
明示的な 8.1 宣言をしないと、GetVersionEx() は Windows 8 の 6.2 を返すという互換性処理がありました。
Windows 10 はどうなのかな…というわけでやってみます。
なお、Windows 10 の supportedOS の guid は MSDN ですでに公開されています。

<!– Windows 10 –>
<supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/>
<!– Windows 8.1 –>
<supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/>
<!– Windows 8 –>
<supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/>
<!– Windows 7 –>
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!– Windows Vista –>
<supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/>

まずは、マニフェストで supportedOS を記述しなかった場合は…

マニフェストなし

内部バージョンは 6.2 で返します。 ということは、Windows 8 ってことか。
次にマニフェストで supportedOS に Windows 8 を記述してみると…

Win8マニフェスト

まぁ、当然ですが、6.2 を返すわけです。
では、supportedOS に Windows 8.1 を記述してみると…

Win81マニフェスト

あー、6.3 ですか。そうですか。
では、最後に supportedOS に Windows 10 を記述してみると…

Win10マニフェスト

おー、きたきた!! バージョン情報が大きく上がった!!
では、まとめます。

OS 名称 バージョン値#1 バージョン値#2 バージョン値#3
Windows 10 10.0
supportedOS に Win10
6.3
supportedOS に Win8.1
6.2
Windows 8.1 / Windows Server 2012 R2 6.3
supportedOS に Win8.1
6.2 N/A
Windows 8 / Windows Server 2012 6.2 
N/A N/A
Windows 7 / Windows Server 2008 R2 6.1 N/A N/A
Windows Vista / Windows Server 2008 6.0 N/A N/A

MSDN に記載がある通りの結果になりました。
Windows 8 まではマニフェストの supportedOS への記述では OS モードだけの差異でしたが、Windows 8.1 以降は
OS バージョンと ビルド番号も変更しています。
しかし、Windows 10 で内部バージョンが一気に上がりましたねぇ。