Remove From My Forums

デスクトップヒープの枯渇

質問
0

サインインして投票
こんにちは。Windows Commercial Storage & High Availability チームの水上です。
今回は、よくあるお問い合わせのひとつである、デスクトップヒープの枯渇について、ご紹介します。

サーバーやデスクトップ PC を運用するにあたって、次のような事象が発生したことはないでしょうか。

他のアプリケーションは正常に動いているのに、アプリケーションの起動やバッチ処理に失敗する。
イベント ID 243 や 244 が記録される。
例外コード 0xc0000142 でイベント ID 1000 が記録される。

上記のような事象は、デスクトップヒープの枯渇により生じている可能性があります。
デスクトップヒープの上限サイズはレジストリで変更が可能なため、設定変更により事象を解消できる可能性があります。

ただ、 “デスクトップヒープの枯渇” という現象が具体的にどういうものなのか疑問に思われる方も多いのが実情です。
実際に、マイクロソフトにいただくお問い合わせの中でも、デスクトップヒープの枯渇とはいったい何なのか詳しく説明してほしいとのご意見をよく頂戴します。
そこで、今回は、デスクトップヒープが何なのかについてもご説明したうえで、デスクトップヒープ枯渇の回避方法についてご紹介します。

もくじ

デスクトップヒープとは何か
デスクトップヒープのサイズ上限とデスクトップヒープの枯渇
デスクトップヒープ枯渇の回避 – デスクトップヒープのサイズ上限の拡張
デスクトップヒープ枯渇の原因調査
おわりに

デスクトップヒープとは何か

デスクトップヒープとは、 Windows 上で作成されるデスクトップに紐づけられる、ウィンドウやメニューなどの情報を格納する領域です。

デスクトップヒープの根底には、セッション、ウィンドウステーション、デスクトップの 3 つの概念があります。
あるユーザーがログオンすると、 Windows の内部ではユーザーのためにセッションが新たに作られます。
(例外として、サービスやタスクの起動のような非対話型の認証が生じた際には、新たなセッションは作られず、共用のセッション Session 0 が使用されます。)
セッションの内部にはウィンドウステーションが作成され、ウィンドウステーションのさらに内部にデスクトップが作成されます。
デスクトップ上には、実際にユーザーに見えるウィンドウやテキストボックスのようなオブジェクト (ユーザーオブジェクト) が作成されますが、このユーザーオブジェクトの情報を保持するのに使用されるのが、デスクトップヒープです。

+++ 参考 +++
セッション・ウィンドウステーション・デスクトップの概念については、下記ページでも詳細に触れられています。

“USER オブジェクトと GDI オブジェクト – 第 1 部”
https://technet.microsoft.com/ja-jp/windows/mark_16.aspx
++++++++++

デスクトップヒープの新規割り当てができなくなると、ウィンドウなどの GUI に必要なデータ構造を作成することができなくなり、アプリケーションの起動失敗などが発生します。

余談とはなりますが、上述のとおり Windows ではユーザーごとにセッションが作成され、セッション稼働中ウィンドウステーションは配下のデスクトップを切り替えながら画面に出力しています。
この仕組みには、次のようなメリットがあります。

同一デスクトップ内の GUI の管理に際し、デスクトップヒープを介したデータやコードの共有が容易かつ安全にできる。
セッション・デスクトップごとのメモリの境界が明確であり、異なるセッション・デスクトップの影響を受けにくい。
特に、ログオン画面や UAC のプロンプト画面は専用のデスクトップを使用しているので、通常のデスクトップの影響を受けにくく、セキュリティ上の脅威を緩和できる。

デスクトップヒープのサイズ上限とデスクトップヒープの枯渇

Windows Server 2008 以降 (Windows Server 2008 R2, Windows Server 2012R2 や Windows Server 2016) では、対話型・非対話型のデスクトップヒープのサイズ上限が、既定値が以下のように設定されています。

対話型: 20480 KB
非対話型: 786 KB

なお、対話型デスクトップとは、通常一般ユーザーが使用するデスクトップで、物理的な画面やキーボードを通じてユーザーとのやり取りが可能なデスクトップです。
一方で、非対話型デスクトップは、サービスやログオン状態にかかわらず実行するように設定されているタスクなど、ヘッドレスの状態で動作するプロセスが使用するデスクトップとして用意されます。

ここで重要なことは、非対話型デスクトップのヒープサイズ上限は、対話型よりも小さく設定されており、対話型のデスクトップヒープよりも枯渇しやすいということです。
本来非対話型のセッションでは GUI を必要としないため、非対話型デスクトップのサイズ上限を厳しくすることは合理的な設計と言えますが、
アプリケーションの挙動次第では、内部的に作成される GUI オブジェクトによりデスクトップヒープが消費されてしまうため、結果としてデスクトップヒープが枯渇しやすくなってしまうのです。
現に、マイクロソフトのサポートには年間数十件ほどのペースでデスクトップヒープの枯渇に関するお問い合わせを頂戴しますが、そのほとんどで非対話型デスクトップヒープの枯渇が問題となっています。

デスクトップヒープが枯渇すると、新たなユーザーオブジェクトを作成することができなくなるため、ウィンドウなどの GUI の維持に必要なデータが配置できず、結果としてアプリケーションの起動失敗や、サービスによりバックグラウンドで実行されるバッチ処理の実行失敗につながります。

殊によくあるのが、大量のバッチ処理をサービスとして並行実行することで、デスクトップヒープが枯渇し、バッチ処理の実行が途中で失敗してしまうというケースです。
cmd.exe と cmd.exe に付随して起動される conhost.exe は、非対話型デスクトップ上でもそれぞれウィンドウやメニューバー、キャレットを持つため、デスクトップヒープを若干 (一般的には数 KB) 消費します。
そのため、非対話型のセッションで多数のバッチ処理を並行して実行すると、小さな消費の積み重ねでデスクトップヒープを消費しきってしまい、結果としてデスクトップヒープが枯渇した状態になります。

+++ 検証 +++

バッチ処理の並行実行による非対話型のデスクトップヒープの枯渇は、下記のように無限ループするバッチファイルを使用して簡単に再現することができます。

重要: 下記は事象の理解の補助のために紹介するものであり、一般ユーザーによる実施を意図したものではありません。
本手順を実際に実行したことによるシステム・データへの損害につきましては、責任を負いかねます。

下記一行が書かれたバッチファイル cmd-loop.bat をデスクトップ上に作成します。
start cmd.exe /K %USERPROFILE%\Desktop\cmd-loop.bat

タスクスケジューラーにて、 cmd.exe を引数 "/K %USERPROFILE%\Desktop\cmd-loop.bat" で実行するタスクを作成します。
タスク作成の際には、 [全般] タブの [セキュリティオプション] の項目で [ユーザーがログオンしているかどうかにかかわらず実行する] が選択されていることを確認します。

作成したタスクを手動で実行します。

手元の検証環境で実際に検証したところ、下記事象が確認できました。

タスクマネージャー上で大量の conhost.exe がセッション ID 0 で稼働しているのが見える (実際には 111 個稼働している)。

システムのイベントログにイベント ID 243 が記録される。

事象発生時のダンプを解析すると、 Session 0 (非対話領域) のとあるデスクトップのヒープが枯渇状態となっている。
**************** > !dskheap -s 0 Winstation\Desktop Heap Size(KB) Used Rate(%) ------------------------------------------------------------ WinSta0\Default 20480 0% // 各セッションにかならず作られる対話型デスクトップ。 Session 0 は非対話型ユーザーセッションなので、原則として使用されない。 WinSta0\Disconnect 96 4% WinSta0\Winlogon 192 2% // ログオン画面で使用するデスクトップ。 Service-0x0-3e7$\Default 768 2% // サービスとして利用されるデスクトップ。サービスの実行ユーザーごとにデスクトップが異なる。 Service-0x0-3e5$\Default 768 0% Service-0x0-3e4$\Default 768 0% Service-0x0-53f57$\Default 768 99% // タスクが実行されているデスクトップ。非対話型。ヒープの使用率が 99 % と枯渇状態。枯渇がどのウィンドウステーション・デスクトップで発生するかは、システムの稼働状況に依存。 ****************

デスクトップヒープ枯渇の回避 - デスクトップヒープのサイズ上限の拡張

デスクトップヒープ枯渇の回避方法としては、次の 2 通りが考えられます。

デスクトップヒープの枯渇を引き起こしているアプリケーションの改修
デスクトップヒープのサイズ上限の拡張

デスクトップヒープのサイズ上限を拡張する方が工数も圧倒的に少なく行えるため、お問い合わせいただいたケースのほとんどでは、サイズ上限の拡張により事象を回避しています。
中には、デスクトップヒープの枯渇が発生することを見越して、サーバー構築時の一手順としてデスクトップヒープのサイズ上限を拡張しておくお客様もいらっしゃいます。

デスクトップヒープのサイズ上限は、下記のレジストリ項目で変更することができます。

場所：HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems
名前：Windows
種類：REG_EXPAND_SZ
データ： SharedSection=XXX,YYY,ZZZ の部分

SharedSection の 1 番目の値 (XXX): 全てのデスクトップに共有されている標準ヒープ
SharedSection の 2 番目の値 (YYY): インタラクティブ (対話型) デスクトップヒープの値
SharedSection の 3 番目の値 (ZZZ): ノンインタラクティブ (非対話型) デスクトップヒープの値

上記 SharedSection の 2 番目や 3 番目の値を大きくすることで、デスクトップヒープのサイズを大きくすることができます。

当該箇所は、長いレジストリ値の一部に含まれていますので、レジストリエディターで確認する際には、手動でカーソルを動かして表示させる必要があります。
また、 SharedSection に誤った値 (たとえば数字以外の文字列) を指定すると、システムが正常に起動しなくなるので、注意してください。

デスクトップヒープ拡張の際には、一般的に、既定値の 2 倍から 3 倍を目安に、徐々に大きくすることをおすすめしています。
値を大きくすることですぐに何か問題が生じるようなことはありませんが、上述したように、上限が緩和され、デスクトップヒープが肥大化するようになると、かえってパフォーマンスの低下 (デスクトップヒープの使用による空きメモリの逼迫や並行するプロセスの増加による処理遅延) を引き起こす可能性があります。
そのため、事象の解消とパフォーマンスへの新たな影響を見ながら、段階的にデスクトップヒープのサイズを拡大するようお願いしています。
>
デスクトップヒープ枯渇の原因調査

デスクトップヒープの消費状況や枯渇の原因の調査の際には、まず完全メモリダンプの採取が可能であるかどうかをご確認いただければと思います。

Windows Server 2003 や Windows XP の時代には、 Desktop Heap Monitor と呼ばれるツールが一般公開されており、デスクトップヒープの状況を簡単に調査することが可能でした。
一方で、 Windows Server 2008 / Windows Vista 以降では、古いツールが使用できなくなっています。

Windows Server 2008 / Windows Server 2008 R2 の場合は、デバッガーや LiveKD を使用してお客様環境でも調査がある程度できましたが、
Windows Server 2012 以降の場合は、完全メモリダンプをご採取いただき、デスクトップヒープの観点でのダンプの解析をマイクロソフトのサポートにご依頼いただく必要があります。

調査を迅速に進めるためにも、デスクトップヒープ関連の問題を調査したい場合は、こちらの記事を参考に完全メモリダンプを採取し、マイクロソフトのサポートまで解析をご依頼ください。

おわりに

デスクトップヒープの枯渇は、特にバックグラウンドでのバッチ処理を行うようなサーバー環境で起きやすく、デスクトップヒープ枯渇に関する調査は多くお問い合わせを頂戴するトピックにもなっています。
他方、デスクトップヒープ枯渇の原因調査にはダンプの採取が必要となる場合が多く、原因調査のハードルは高めであるといえます。

デスクトップヒープの拡張は、すぐにシステムの稼働に影響を与えるような作業ではありません。
マイクロソフトが把握している事例においても、デスクトップヒープを 2 倍から 3 倍程度増やしたことで他の問題が発生したとの報告はない状況です。
そこで、

他のアプリケーションは正常に動いているのに、アプリケーションの起動やバッチ処理に失敗する。
イベント ID 243 や 244 が記録される。
例外コード 0xc0000142 でイベント ID 1000 が記録される。

このような事象が発生した際には、まずは上記でご紹介したレジストリ変更を実施し、事象が回避できるかどうかをお試しいただければと思います。
デスクトップヒープの拡張でも事象が解消しない場合には、お気軽にマイクロソフトのサポートにご相談いただければ、課題解決にむけ可能な限りご支援させていだきます。

アプリケーションの起動やバッチ処理に失敗する問題について、詳細な調査をご希望の場合は、まずは完全メモリダンプのような再起動を伴う情報採取が可能かどうかをご確認いただいたうえで、マイクロソフトのサポートにお問い合わせいただけますと幸いです。

いかがでしたでしょうか。本投稿が少しでも皆様のお役に立てば幸いです。

(※ 2018 年 01 月 09 日に Ask Core Microsoft Japan Windows Technology Support に公開した情報のアーカイブです。)
- 編集済み jpcore2 2019年3月17日 16:02
2019年3月17日 15:58

jpcore2

35,318

ポイント

トップ 0.5

jpcore2

参加: Sep 2012

2

2

3

jpcore2 のスレッド

アクティビティを表示

35,318 ポイント