Windowsのシャットダウンを高速化するレシピ――そのレシピは本当においしいのか？：その知識、ホントに正しい？ Windowsにまつわる都市伝説（205）

Windowsのシャットダウンを高速化するといわれる3つのレシピ「HungAppTimeout」「WaitToKillAppTimeout」「WaitToKillServiceTimeout」。この中の1つに、もはや何の意味も持たない無駄なものがあります。分かりますか？

[山市良，テクニカルライター]

Windowsにまつわる都市伝説

訂正されることなく流布される誤ったレシピ

　インターネット初期から脈々と続く、おいしいクッキーのレシピの書かれた伝説の迷惑メールがあるとかないとか、そして作ってみたら本当においしかったとかそうでなかったとか、今回取り上げるトピックを調査していたら、そんな話をふと思い出しました。

　インターネットで「HungAppTimeout」「WaitToKillAppTimeout」「WaitToKillServiceTimeout」の3つをキーワードに検索してみてください。Windowsのシャットダウンを高速化するレシピ（テクニック、Tips）として、たくさんの情報が見つかると思います。

　具体的には、以下のレジストリ値になります。いずれもREG_SZ（文字列）型のレジストリ値、「HKCU」は「HKEY_CURRENT_USER」、「HKLM」は「HKEY_LOCAL_MACHINE」と同じ意味を持つ省略形です。これらのレジストリ値は、シャットダウン時にアプリケーションを「応答なし」と見なす、あるいはサービスに対して停止処理を実行する機会を与えるためにシステムが待つタイムアウト値を調整するといわれるものです。

• HKCU\Control Panel\Desktop\HungAppTimeout
• HKCU\Control Panel\Desktop\WaitToKillAppTimeout
• HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout

　実はこのレシピには、もう役に立たないものが1つ紛れ込んでいます。それは2つ目の「WaitToKillAppTimeout」です。実証してみましょう。

　今回、素材として「Windows XP」「Windows 7」「Windows 8.1」「Windows 10」を、調理道具としてWindows Sysinternalsの「Process Monitor」（Procmon.exe、Procmon）を用意しました。

　Procmonは、Windowsのプロセスが行うレジストリやファイル、ネットワークのI/Oをリアルタイムにキャプチャーするツールです。このツールには「ブートログ（Boot Logging）」という機能もあり、この機能を使うと次回のブートの早い段階から、次にProcmonを起動するまで継続してキャプチャーすることができます。これを使って、ブートから起動して、ユーザーがログオンし、Procmonを停止するまでに行われた「HKCU\Control Panel\Desktop\」へのアクセスをキャプチャーしてみます（画面1、画面2）。

画面1　Procmonのブートログ（Boot Logging）機能を有効にして、コンピュータを再起動する

画面2　再起動後、Procmonを起動してキャプチャーデータを保存し、保存したログのキャプチャーデータが表示されたらこのようなフィルターを設定する

　以下の画面3は、Windows 10のキャプチャーデータを、画面4はWindows 7のキャプチャーデータを示したものです（Windows 8.1も同じなので省略）。

画面3　Windows 10のキャプチャーデータ。「HungAppTimeout」のすぐ後に参照しているのは、「WaitToKillAppTimeout」ではなく「WaitToKillTimeout」

画面4　Windows 7のキャプチャーデータ。Windows 10と同じレジストリ値を参照している

　つまり、正しい組み合わせは以下の3つになります。3つのレジストリ値の既定値は5000ミリ秒、つまり5秒です。「HungAppTimeout」と「WaitToKillTimeout」は既定では存在しませんが既定値が適用されます。

• HKCU\Control Panel\Desktop\HungAppTimeout（値が存在しない場合の既定は5000ミリ秒）
• HKCU\Control Panel\Desktop\WaitToKillTimeout（値が存在しない場合の既定は5000ミリ秒）
• HKLM\SYSTEM\CurrentControlSet\Control\WaitToKillServiceTimeout（既定は5000ミリ秒）

　ちなみに、「HungAppTimeout」と「WaitToKillTimeout」はユーザーアプリケーション用のタイムアウト値で、「HungAppTimeout」値はファイルの保存など、応答を待っているウィンドウ（アクティブなトップレベルウィンドウ）を持つアプリケーションの応答なしを判断するのに使用されます。応答なしと判断された場合、画面5のような、皆さんがよく目にする画面が表示され、シャットダウンはユーザーが介入しない限り、そこで永遠に中断します。

画面5　「HungAppTimeout」値に基づいて、ウィンドウを持つアプリが応答なし（ファイルの保存待ちなど）と判断され、シャットダウンがストップする

　アプリが最近のWindows 10や「Windows 11」の「アプリの再起動（再起動可能なアプリをサインアウト時に自動保存し、サインイン後に再起動する）」（アカウントのサインインオプションの一つ）に対応している場合、この画面は表示されません。例えば、Windows 11の場合、「メモ帳」で未保存のファイルを編集中であっても、メモ帳で作業中の情報が保存されるため、応答なしの対象にはなりません（メモ帳がユニバーサルWindowsプラットフォーム《UWP》化され、アプリの再起動に対応したからです）。

　「WaitToKillTimeout」は、シャットダウン通知をしてもらうように登録済みのコンソールアプリのためのタイムアウト値です。タイムアウト値に達しても、前出の≪画面5＞のような中断は発生しません。そのままシャットダウン処理が続行します。

　そして、「WaitToKillServiceTimeout」は先ほど説明したように、サービスに対して停止処理を実行する機会を与えるためにシステムが待つタイムアウト値です。このタイムアウト値も、システムが終了処理を行う各サービスに対して待機してあげる時間であって、その時間が過ぎれば粛々とシャットダウン処理を進めます。

　いずれの既定値もたったの5秒、コンピュータから見れば長い時間かもしれませんが、人から見れば一瞬のことです。これをチューニングして、さらに高速化するなど、ほとんど意味がないことでしょう。

　どちらかといえば、「HungAppTimeout」は「アプリの再起動」対応のウィンドウアプリが増えていけば影響を受けることはなくなるでしょうし、他の2つのレジストリ値は短縮するよりも、適切なシャットダウン処理のために長めに調整するという使い方が今では適しています（サーバ用途では特にそうです）。

古過ぎる情報源には要注意

　では、「WaitToKillAppTimeout」というレジストリ値はどこからきたものなのでしょうか。実は、Windows XPや「Windows 2000」「Windows Server 2003」までは実際に使われていたものでした。以下の画面6は、Windows XPで先ほどと同じ実験をしたものです。キャプチャーデータを見ると、確かに「WaitToKillAppTimeout」を見に行こうとしています。

画面6　Windows XPのキャプチャーデータ。「HungAppTimeout」と「WaitToKillAppTimeout」を探している

　最初にリストアップした3つのレジストリ値の説明を公式ドキュメントで探すと、Windows 2000やWindows Server 2003のものがヒットします。新しい（おそらく「Windows Vista」以降）「WaitToKillTimeout」について説明しているドキュメントは筆者が探した限りでは見つけることができませんでした。

• HungAppTimeout（Windows Server 2003 Deployment Guide）［英語］（Microsoft Docs）
• WaitToKillAppTimeout（Windows Server 2003 Deployment Guide）［英語］（Microsoft Docs）
• WaitToKillServiceTimeout（Windows 2000 Server）［英語］（Microsoft Docs）

　最後の「WaitToKillServiceTimeout」のドキュメントで説明されている既定値にも注意が必要です。当時、既定値は「20000ミリ秒（20秒）」と長いものでした。なので、当時は、短縮することで高速化が期待できたわけです。「WaitToKillServiceTimeout」の既定値は、Windows 7とWindows Server 2008 R2のこのレジストリ値が期待通りに機能しないという不具合を解決する更新プログラムの提供と同時に、既定値が「12000ミリ秒（12秒）」に少し短縮されました。

• WaitToKillServiceTimeout registry value does not work in Windows 7 or in Windows Server 2008 R2［英語］（Microsoft Support）

　そして、Windows 8およびWindows Server 2012で「5000ミリ秒（5秒）」にさらに短縮され、今に至っています。「WaitToKillServiceTimeout」の既定値が「5000ミリ秒（5秒）」に変更されたというドキュメントは見当たりませんが、Windows 8およびWindows Server 2012以降のクリーンインストールでは「WaitToKillServiceTimeout」値にこの既定値が設定済みという事実が示しています。

筆者紹介

山市 良（やまいち りょう）

岩手県花巻市在住。Microsoft MVP 2009 to 2022（Cloud and Datacenter Management）。SIer、IT出版社、中堅企業のシステム管理者を経て、フリーのテクニカルライターに。Microsoft製品、テクノロジーを中心に、IT雑誌、Webサイトへの記事の寄稿、ドキュメント作成、事例取材などを手掛ける。個人ブログは『山市良のえぬなんとかわーるど』。近著は『Windows版Docker＆Windowsコンテナーテクノロジ入門』（日経BP社）、『ITプロフェッショナル向けWindowsトラブル解決 コマンド＆テクニック集』（日経BP社）。