メモリが解放されない？

ご意見ありがとうございます。

> VirtualAlloc() API が提供する機能をちゃんと理解できていますか？

> （というか、「仮想メモリ」と「物理メモリ」の区別がちゃんとできていますか？）

「仮想メモリ」「物理メモリ」は区別できていると思いますが、考えてみると「コミット済みメモリ」の定義についてはまだ理解が少し曖昧なきがします。

>>  「呼び出し側プロセスの仮想アドレス空間内のページ領域を、予約またはコミットします。」

> つまり、この API を呼び出したところで、物理メモリにはなんら影響を与えない。。。ということではないでしょうか？

この点（と私が書いたというテストプログラムの件）については、謝らなければなりません。

VirtualAllocではMEM_RESERVE|MEM_COMMITフラグを渡している、という情報が抜けていました。

このフラグを設定しているので、VirtualAllocで与えられたメモリにはアクセスが可能となっています。実際、書き込みができることを確認したプログラムでした。

それから、私の理解ではMEM_COMMITを渡しているということは、具体的に物理メモリがマッピングされたか、あるいは、ページファイル上にアクセスできるメモリ領域が確保されたことだと理解しています。間違いないですよね？

> VirtualAlloc() API でコミットした「仮想メモリ上の領域」が「物理メモリ」上にマップされるのは、基本的に VirtualLock() - VirtualUnlock() の間だけのはずです。

いやVirtualLock()~VirtualUnlock()間は、そのメモリ範囲がページファイルにスワップされないことが保証されるということだったはず。

MEM_COMMITフラグを伴ってVirtualAllocすれば、そのメモリにはアクセスできるが、その段階で物理メモリにあるかページファイルにあるかはOS次第で、ページファイルにあるときにアクセスすればページフォールトが発生して、OSが読みだして物理アドレスを与えてくれる、という動作のはずです。

それから、全部のレスを読まれていないので仕方がありませんが、このスレで私は一度も物理メモリ（アドレス）の議論をしてきたことはありません。あくまでも、タスクマネージャ上での「使用中」と「コミット済み」のメモリ量の関係を議論してきました。

**>**提示されているサイトは、特定のプロセスにおける「仮想アドレス空間」のメモリ マップ状態を調べる方法だと思います。（ちゃんと読んでないけど。）

今は、explorer.exeとtaskhostexe.exeのメモリの使い方が怪しいと疑っている段階なので、むしろプロセス単位でのメモリの内容が分かるほうがありがたいのです。ここでも物理アドレスは全然気にしていなくて、仮想アドレス空間上でどのようにメモリを使っているかがわかると、そのうち何MByteが「使用中」メモリで、何MByteが「コミット済み」メモリなのかが調べられると思って、注目しているところです。

> WinDBG はソフトウェア開発者ですら敬遠する解析ツールですが、もし挑戦する根性があるのでしたら、ぜひ頑張ってください。

WinDBGは最近は使っていませんが、10年くらい前まではドライバの開発でデバッグで大変お世話になりました（当時はRS232C接続のリモートデバッグで非常に苦労した思い出が・・・）。

コマンドベースなので、まだまだすべての機能を使いこなせているとは思えませんが、ダンプファイルから解析するという方法は考えつかなかったので検討してみたいと思います。ありがとうございました。

> 個人的には、本スレッドはこのコミュニティで扱う範疇を超えているような気がしています。

そのとおりだと思います。

最初は、同じような人がいて解決策がサクッと分かったらいいな、くらいの軽い気持ちでした。あるいは、MSがホストのフォーラムですから、モデレータの方が我々の知らない情報に通じていて、いいアドバイスをくれるのではないかとも期待していました。

しかし、モデレータとはもったいぶった言い方で、moderate（穏やか）という言葉から察するに、結局は某掲示板のように炎上しないように監視しているだけに過ぎないのかも知れませんね。そういう意味でもこのフォーラムでのこの質問はもう不適切でしょうね。

タスクバー上やタスクマネージャー上アプリのカテゴリー上には無いが

裏で依然プログラムが動いていて、それがコミットしているというケースが結構あります。

IE等、全てのウインドウを閉じたのに何故か残っている・・・等。

僕の使い方は結構ハードな使い方をしていて、ウインドウを数十多重にあげることが多いせいか

余計にそのような事がおきるのですが、（しかもIEはウインドウごと敢えて別プロセスで実行）

腹が立ったためにそのアプリケーションを一度全部とじても大丈夫！という状態になった場合、

管理者モードで起動したコマンドプロンプト上で　"taskkill"  コマンドにて強制的にぶった切って

解放するようになりました。

構文

　taskkill /f /t /im プログラムのファイル名

/f : プロセスの強制終了指定

/t : ぶら下がっている子プロセスまで終了対象とする ＜これが無いと残骸が残る事があります。

/im : プログラムのファイル名を指定対象とする

面倒なので個人的にブラウザ（IE）に関しては（ウインドウが開いている状態でも）

バッチファイルを作って終了させてます。

"taskkill /f /t /im iexplore.exe"

特定のウインドウだけの終了（メモリー解放）の場合はプロセスIDが探せる場合であれば

/im の代わりに /pid プロセスID に書き換えればそのウインドウと

/t ならぶら下がっているプロセスも解放してくれます。

（が、残したいウインドウがぶら下がっていない事の確認は必要）

ただし /t で　　Explorer.exe  をぶった切る場合は殆どのアプリケーションが

Explorer にぶら下がって動作しているので、共倒れ（道連れ）終了させてしまいますので注意が必要です。

差支えないようでしたらお試し下さい。

なかなか解決しないですね。

WindowsUpdateでいつか解決するかなと思ってたんですが・・・。

VMMapを使った結果もmuranoさんと同じような結果でした。

explorerを調べると5GBくらいCommitedになってました。

サイズ順に並べると50MB～1MBのものが大量にありました。

Address欄の一番右の項目を見ても内容がバラバラなので

何が問題なのか一般人には推測することも難しかったです。

Windows10の開発のほうが進んでいるようなので、

もうWindows8系は諦めたほうが良いんでしょうか。

> そりゃ休止状態を使えば使うほどコミットメモリは増加する思う、既知の常識。

すみません。これが常識だということは初めて聞きました。「常識」＝「説明するまでもない」ということかもしれませんが、常識であればどこか他でもそういう書き込みなり情報があるはずだと思います。どこか一つでもよいので例示していただけませんか？

（自分も含めて）いろいろな人がいますので、あまり考えすぎずに（相変わらず）「Windowsは(環境によっては）メモリの使い方がダメダメなOSなんだということは既知の問題です」ぐらいに捉えておくといいのではないですかね。

Linuxなどをみてもｘ86のOSだからメモリは4GB弱しか使用できないということではありませんし、WindowsというOSのメモリマネージマントに根本的な問題があるのかもしれませんね。