普段どの環境でも200MB程度で動いてるexeが、ある環境だと1GBを超えてメモリを消費する (結果OSのメモリ不足として問題が顕在化する) という事象で、特定の環境でしか起きないのであれば、その環境特有のものが原因では? (例えばセキュリティソフト) といった考え方がある。そうかもしれないけど、タスクマネージャ見るとexeがメモリを食ってて (セキュリティソフトはメモリ食ってない)、セキュリティソフトが他のプロセスのメモリサイズに割って入ってくることってあるのか?? ともやもやしてた (今回専用メモリ領域が大きいのだが、専用メモリ領域ってそのプロセス専用の領域であって、それをセキュリティソフトという他プロセスが消費することなんてできるのか?? OSのセキュリティで各プロセスの専用メモリ領域って隔絶されてるのではないのか??)
で、その件とは関係なく、WinDbgで「gflags /i xxxx.exe +ust」を有効化するとどのくらいリッチな情報が取れるのか知るため、手元で適当な大きさのファイルをサクラエディタに読ませて、gflags無効だどこまでのメモリ調査が限界で、gflags有効化後はさらにどこまで調べられるのか、を検証していた
その検証で、タイトルの「セキュリティソフトが他のプロセスのメモリ領域を消費する(ことができる)」ということが分かり、記事にしました
まず、サクラエディタで110MBくらいのテキストファイルを読み込ませると、タスクマネージャ上でコミットサイズ570MB、ワーキングセット600MBちょっとになる
タスクマネージャでsakura.exeのダンプファイルを出力すると、ダンプファイルのサイズも600MBちょっと
このダンプファイルをWinDbgに読み込ませて、メモリ調査関連のコマンドを実行 & 生成AIで解析、を繰り返した結果、以下のような情報を得た (xxxxxxxxはセキュリティソフト名 / セキュリティソフトのdll名)
- xxxxxxxx.dll がサクラエディタのプロセス内にロードされ、実行スタックの最上位を占拠しています。
- サクラエディタの関数（sakura+0xe5d92）のすぐ上で、xxxxxxxx が動作していました。これは、サクラエディタがメモリ確保やファイル操作を行うたびに、xxxxxxxx がその処理を「横取り（フック）」して割り込んでいる決定的な証拠です。
- 異常な領域数 (RgnCount: 6876):
- サクラエディタ単体でこれほど細切れに VirtualAlloc を繰り返すことは稀です。一方で、エンドポイントセキュリティ製品（EDR）は、プロセスの挙動を監視するために独自の管理テーブルをメモリ内に大量に作成する特性があります。
- メモリ肥大の理由: !address -summary で見られた 6,800 個もの大量の領域（RgnCount） は、セキュリティソフトが検査のために細かくメモリを確保・スキャンしているときによく見られる挙動です。
- メモリの中身 (dc / dps の結果):
- 04d80000 付近にあったのはテキストではなく、ポインタやフラグが並ぶ「構造体（管理データ）」でした。サクラエディタが保持するデータであれば Unicode 文字列が見えるはずですが、それが見えないということは、「監視ソフト側の管理用ワークエリア」 である可能性が極めて高いです。
- サクラエディタそのものがメモリを消費しているのではなく、サクラエディタの動作（巨大ファイルを開く、あるいは大量の行処理）を監視しようとした xxxxxxxx が、解析バッファとして大量のメモリを確保し、サクラエディタのプロセス空間を圧迫している 状態です。
- 今回の 500MB 超のメモリ消費は、「サクラエディタの動作を xxxxxxxx が監視・解析するために、サクラエディタのプロセス空間内に勝手に広げた作業机」 のようなものです。
- xxxxxxxx のようなセキュリティ製品が原因のケースは WinDbg を使わないとまず見抜けない「隠れた原因」の典型例です。
なのでタイトルの「セキュリティソフトが他のプロセスのメモリ領域を消費する(ことができる)」はあると。
なお生成AIの言う通り、exeのパスやプロパティを見るとセキュリティソフトでした
なお元々の検証目的であった「WinDbgで「gflags /i xxxx.exe +ust」を有効化するとどのくらいリッチな情報が取れるんだろう」は、サクラエディタのダンプだとgflagsなしで結論がでてしまったため、まだ検証できてません..