| [System Environment] | |||||||||||||
原因不明のメモリ不足エラーに対処する方法(デスクトップ・アプリケーション・ヒープ不足エラーに対処する方法)
|
|||||||||||||
|
|||||||||||||
| 解説 |
16bitの流れを汲むWindows 9xには、システム・リソースと呼ばれるWindowsシステムの作業用メモリ領域があり、新しいウィンドウが生成されたときや、ウィンドウへのグラフィックス描画がなされたときなど、作業データがこの領域に確保されるようになっている。Windows 9xの原点とも呼べるWindows 3.0では、ウィンドウ管理用(USERリソースと呼ばれていた)やグラフィックス描画用(GDIリソースと呼ばれていた)として、それぞれ16bitアドレッシングによる1セグメント(64Kbytes)のメモリ領域が割り当てられていた。残念なことにWindows 3.0では、ウィンドウを幾つか同時に開いたり、巨大なアプリケーションを実行したりすると、特にこのうちのUSERリソースが不足することが多かった。システム・リソースが不足すると、アプリケーションで使用可能なメモリ領域はまだ残っているにもかかわらず、メモリ不足エラーが発生することになる。困ったことに、システム・リソースはWindows自身がそのサイズを固定的に取り決めている管理領域であり、物理的にメモリ・モジュールを増設したりしてもサイズは増えないことだ。
![]() |
| Windows 3.0の使用可能システム・リソース |
| Windows 3.0ユーザーを悩ませてきたシステム・リソース。たった64Kbytesの領域を使いきると、通常のメモリがいくらあっても「メモリ不足エラー」になってしまった。画面はWindows 3.0のプログラム・マネージャから使用可能システム・リソースを確認したところ。もはや残りは6%しかない。 |
これに対しマイクロソフトは、Windows 3.1において、USERリソース用のセグメントを2つ(128Kbytes)に倍加し、リソース不足の問題を回避した。さらにカーネルの32bit対応を行い、4Gbytesのメモリ領域をフラットにアドレッシング可能になったWindows 95では、過去との互換性を維持するうえで必要な要素を下位64Kbytesに残しながら、それ以外のデータは上位のアドレスを使用可能にし、リソース不足問題をほぼ抜本的に解消した(ただし、互換上残された64Kbytesの制限はなくなったわけではない)。
いうまでもなく、当初から32bitシステムとして設計されたWindows NT(およびその後継のWindows 2000/XP)では、基本的にこのような16bit時代の呪縛は残っていない(以下、特にバージョンに言及する必要がないかぎり、Windows NTコアを持つすべてのWindows OSを総称して「Windows 2000/XP」と表記する)。実際、Windows 2000/XPを使っていても、利用可能メモリは残っているのもかかわらず、メモリ不足エラーが発生するというWindows 3.x当時のようなトラブルはめったに発生しないし、そもそもWindows 3.xユーザーの間ではたびたび話題に登った「システム・リソース」という言葉自体もあまり聞かれなくなった。Windows 2000/XPでは、システム・リソースの制限はなくなったのか?
Windows 2000の「デスクトップ・アプリケーション・ヒープ」とは?
残念ながら、システムの作業領域が不足することによるメモリ・エラーは、Windows 2000においても発生する可能性がある。これは「デスクトップ・アプリケーション・ヒープ(desktop application heap)」と呼ばれる領域に起因するものである。これはWindows 2000デスクトップで実行される、すべてのウィンドウ・ベースのアプリケーションが使用する領域で、実行されるすべてのプロセスのメモリ空間にマップされ共有される。そして内部には、ウィンドウ管理情報やメニュー・データ、アプリケーションによって作成されたペン、アイコンなどが作業用として保存される。用途としては、ちょうどWindows 3.xのUSERリソースとGDIリソースを1つにしたようなものと考えればよいだろう。このデスクトップ・アプリケーション・ヒープ領域のサイズは、Windows 2000の起動時に決定され、不足したからといってダイナミックに増やされたりしない。つまりWindows 3.xのシステム・リソースと同様の問題が生じる可能性があるわけだ。
マイクロソフトは、この件に関するサポート技術情報を公開している。
このドキュメントを読むかぎり、対象となるOSはWindows NTからWindows 2000までで、Windows XPは対象にはなっていない(さらにマイクロソフトのサイトを検索してみたが、関係がありそうな情報は見付からなかった)。単にドキュメントが更新されていないだけなのか、Windows XPでは、Windows 2000から比較してデスクトップ・アプリケーション・ヒープに関する何らかの対応が加えられ、問題が解消しているのかは不明だ。ただし、以下で述べるレジストリ設定については、Windows XPもWindows 2000と同じであった。以下、本稿ではWindows 2000を対象として話を進めるが、Windows XPを使っていて同じような症状に遭遇したときには、同様の方法で対処してみるとよいだろう。
デフォルト・サイズは3Mbytes、制限する理由はパフォーマンスの低下回避
しかしこのような制限を加える理由は、Windows 9xがその理由とする互換性維持ではない。前述したとおり、このデスクトップ・アプリケーション・ヒープは、すべてのプロセスのメモリ空間にマップされるため、これが不用意に大きくなると、システム・パフォーマンスに重大な影響を及ぼすからだ。ちなみにWindows NTの初期バージョンであるVer.3.1では、デスクトップ・アプリケーション・ヒープのデフォルト・サイズは3Mbytesだったが、次のVer.3.5では、パフォーマンス向上を目的として512Kbytesに縮小された(Windows 2000/XPでは3Mbytesに戻されている)。NT 3.5の大きな特徴の1つはパフォーマンスの向上だった(Windows NTの歴史の詳細については、「特集:Windows 2000とは何か? 『コラム:Windows NTの歴史』」を参照)。つまりデスクトップ・アプリケーション・ヒープのサイズは、それだけシステム性能に及ぼす影響が大きいという証である。
マイクロソフトの資料によれば、512Kbytesで約2500個のウィンドウを開くことが可能としている。従って3Mbytesなら、単純計算では1万5000個のウィンドウを開けることになる。この数字だけ見れば、デスクトップ・アプリケーション・ヒープが不足するなど到底想像できないだろう。それではなぜ、これが不足するような事態が発生するのか?
最も考えられる原因は、アプリケーションのバグ
この理由として最も単純に考えられるのは、アプリケーションのバグである。一般に、取得したメモリ領域を、それが不要になっても正しく解放せず、領域の取得を繰り返すことをメモリ・リーク(memory leak。「leak」は「漏れ出た水」の意)と呼ぶ。デスクトップ・アプリケーション・ヒープ不足は、この領域上でメモリ・リークを起こしているアプリケーションが存在している可能性が高い。このようなとき、デスクトップ・アプリケーション・ヒープ領域が必要に応じて拡張される仕様になっていたら、システムのメモリ領域はこのメモリ食いのバグに食べ尽くされてしまうだろう。デスクトップ・アプリケーション・ヒープのサイズが固定されている理由の1つはこれである。
| 設定方法 |
レジストリを修正する前に
デスクトップ・アプリケーション・ヒープが不足すると、新たにアプリケーションを起動しようとしたとき、アクティブ・ウィンドウを切り替えようとしたときなどに、突然「メモリ不足エラー」が通知される。あるいは、このメモリ領域の性格上、「メモリ不足エラー」メッセージ・ボックス自体を正しく表示することすらできないかもしれない。
デスクトップ・アプリケーション・ヒープのサイズは、レジストリに記録されているので、これを修正して大きな値にすれば、起動時のデスクトップ・アプリケーション・ヒープを増加させることができる。以下にこの方法を述べるが、レジストリを修正する前に、そのエラーが発生した時点で実行されているアプリケーションなどを調べ、メモリ・リークを起こしていそうなものがないかどうかを検討しよう。そして思い当たる節があるなら、そのアプリケーションの使用中止を検討しよう。前述のような理由から、デスクトップ・アプリケーション・ヒープの増加によって、システム・パフォーマンスは低下してしまうからだ。こうした段階を踏んでも、初期値を増加するしかない場合にかぎり、レジストリを修正するようにしよう。
レジストリを修正する
| [注意] |
|
レジストリに不正な値を書き込んでしまうと、システムに重大な障害を及ぼし、最悪の場合、システムの再インストールを余儀なくされることもあります。レジストリ・エディタの操作は慎重に行うとともに、あくまで御自分のリスクで操作を行ってください。何らかの障害が発生した場合でも、本Windows Server Insider編集部では責任を負いかねます。ご了承ください。 |
レジストリ・エディタを起動し、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystemsキーを表示して、データ一覧から「Windows」をダブル・クリックするか、「Windows」を選択して[編集]−[変更]メニューを実行する。レジストリ・エディタを起動するには、エクスプローラから%windir%regedit.exeを実行するか、[スタート]ボタンの[ファイルを指定して実行]を選択し、表示されるダイアログで「regedit」と入力して[OK]ボタンをクリックすればよい。レジストリ・エディタは、[スタート]−[プログラム]メニューなどには登録されていない。
![]() |
||||||
| レジストリ・エディタを起動する | ||||||
| レジストリ・エディタを起動したら、HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\SubSystemsキーを表示し、データ一覧から「Windows」をダブル・クリックする。 | ||||||
|
すると次のような[文字列の編集]ダイアログが表示される。
![]() |
|||
| [文字列の編集]ダイアログ | |||
| デスクトップ・アプリケーション・ヒープを変更するには、ここで[値のデータ]にあるパラメータを修正する。 | |||
|
![]() |
|||
| 「SharedSection」のパラメータ | |||
| [値のデータ]でカーソルを移動し、「SharedSection」パラメータを見付ける。 | |||
|
ここには、Win32サブシステムの起動時のオプションが記述されている。デスクトップ・アプリケーション・ヒープの初期値は、このオプション中のSharedSection=xxx, yyy」の「yyy」で、ここにKbytes単位でサイズを指定する。例えばWindows NT 3.5なら、デフォルト設定は次のようになっているはずだ。
SharedSection=1024, 512
Windows 2000およびWindows XPでは、デフォルト設定は次のようになっている。
SharedSection=1024, 3072
いずれも、第1パラメータ(1024)はグローバル・ハンドル・テーブルなど、すべてのデスクトップで共有されるシステム設定用領域で、これを変更する必要に迫られることはまずない。
前述のとおり、デスクトップ・アプリケーション・ヒープのWindows NT 3.5でのデフォルト・サイズは512Kbytes、Windows 2000/XPでのデフォルト・サイズは3Mbytes(3072Kbytes)である。ヒープ不足を解消するには、この値を増加させるわけだが、この値がWindowsシステムに与える影響は大きいので、くれぐれも慎重に増加させていただきたい。通常は256Kbytesや512Kbytes単位に増加させれば問題を解消できるはずだ(それでも問題を回避できないときは、前述のとおり別の道を検討すべきである)。
場合によっては、「SharedSection=」オプションに第3のパラメータが存在することがある。
SharedSection=1024, 3072, 512
この第3のパラメータ(512)は、ノン・インタラクティブなプロセスに割り当てられるデスクトップ・ヒープのサイズである。こちらも修正に迫られることはまずないので無視してよい。
|
||||||||||||||||||||||||||||
|
更新履歴 |
|
|
| 「Windows TIPS」 |
ホワイトペーパー(TechTargetジャパン)
- WindowsTIPS (2010/3/19)
− [シャットダウン]ボタンの設定を変更する
− WINSサーバをインストールする
− WINSサーバをnetshコマンドで管理する - Windows 7のファイアウォール機能 (2010/3/18)
Win 7のファイアウォールの概要解説。ルールセットを切り替えるプロファイル機能が強化され、ドメインでもVPNでも、適切なルールが自動選択される - 第212話 プリンタ用紙 (2010/3/16)
致命的なディスク・クラッシュが起きる確率は、クラッシュによってもたらされる被害の大きさに比例する… - WindowsTIPS (2010/3/12)
− 不要なアドオンを無効化してIE8の起動を高速化する
− IE8のソース表示エディタを変更する
− RRASのNATでポートマッピングを定義する
|
|
スキルアップ/キャリアアップ(JOB@IT)
スポンサーからのお知らせ
- - PR -
| 「いつかは壊れるサーバ」そんな故障に 迅速で安価に手軽に対応する方法とは? New! |
| 「特権ユーザー」の事件を防げ! 万能権限を持つユーザーの管理方法とは? New! |
| 仮想環境の構築とデータ保護の特効薬?! 実績と信頼性の高いパッケージで安心運用 |
| 仮想環境のバックアップもこれまでどおり 「まるごと取ってまるごと戻す」簡単運用 |
| おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |
| その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |
| 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |
| 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |
- - PR -
お勧め求人情報

**先週の人気講座ランキング**
〜CCNA編〜
| ◆ | TomcatやJBossなどAPサーバ環境に関する 情報を集約! “業務”用APサーバ大百科 New! |
| ◆ | 一気に解説! 最新のクラスタストレージ 「RAIDを超えたストレージ基準」……など New! |
| ◆ | クラウド的ユーザー体験の変化は脅威か? 仮想化技術を使いこなす運用管理術を紹介 New! |

| ◆ | 上司や部下、部署内メンバーとの情報共有 を“ガラッ”と変えるコラボツールとは? New! |
| ◆ | おばかアプリ選手権、第4弾開催中!! ムダにカッコよくてくだらない作品求ム! |
| ◆ | 社内ファイルサーバを“クラウド”に統合 VPN直結「クラウド型ストレージ」を紹介 |

| ◆ | Twitterのアカウントはなぜ突破された? メールによる新手の攻撃手法とその対策 |
| ◆ | もう仮想化のお試しフェイズは終わりだ! Hyper-V 2.0が基幹システムも仮想化 |
| ◆ | 美人!? まあまあ? 気になる いやし系!! PV急増で「美人時計」がとった手段とは? |

| ◆ | クライアント企業から求められる人材 ⇒IT技術と経営戦略を併せ持つ「戦略家」 |
| ◆ | .NET編集長が実践する「技術情報検索術」 サンプル・コードを簡単に探す“技”は? |
| ◆ | 業務効率と情報セキュリティ対策を両立! 手間なく確実に機密情報を守る方法とは? |

| ◆ | 進化を続ける富士通ストレージETERNUS DX 製品開発者の自信を裏付けるものとは何か |
| ◆ | 運用管理の課題を“2つの観点”から分析 ユーザー満足度の高い「仮想環境」とは? |

| ◆ | 【CTC事例】約30の基幹システムを統合! 膨大なバッジジョブを制御した方法は? |
| ◆ | 仮想化すればコストは削減できるか? 仮想化に必要な「3つの視点」を解説する |
| ◆ | その数、なんと400台以上! グループ内 サーバの「統合管理」によるメリットは? |











