Windows で AI エージェント / Node プロセスが exit code 3221226505 で突然死する時の診断手順

Error: <tool> process exited with code 3221226505 を見たら、この順で切り分ける。 アプリ側のコードを読み始める前に、まず環境側の資源を見る。推定で終わらせず必ず実測する。

0. 終了コードの意味

• 3221226505 = 0xC0000409 = STATUS_STACK_BUFFER_OVERRUN
• 名前は誤解を招く。実際の意味は __fastfail＝プロセスが「続行不能」と判断して自ら即死した。 メモリ破壊バグではないことがほとんど。
• 同じコードを返す原因が複数あるので、コードだけで断定してはいけない。

原因	頻度	見分け方
Windows のコミット制限（RAM＋ページファイル）枯渇	最多	同時刻に無関係なアプリも落ちている
Node の libuv assertion	中	stderr に Assertion failed: がある
V8 単体のヒープ OOM	少	stderr に JavaScript heap out of memory がある
ネイティブモジュールの ABI 不一致・破損	少	WER に faulting module（DLL 名）が残る

1. stderr を先に見る（ここで多くが決まる）

• Assertion failed: があれば libuv。以降のメモリ調査は不要。
• JavaScript heap out of memory / FATAL ERROR: ... Allocation failed があれば V8 単体 OOM。
• どちらも無ければ コミット枯渇を最有力として次へ。

2. イベントログ（決定的な手がかり）

Get-WinEvent -FilterHashtable @{LogName='Application'; StartTime=(Get-Date).AddHours(-6)} |
  Select-Object TimeCreated, ProviderName, @{n='H';e={($_.Message -split "`r?`n" | Where-Object {$_ -match '\S'} | Select-Object -First 4) -join ' ~ '}} |
  Format-List

見るべきもの:

• 0x800705AF（ERROR_COMMITMENT_LIMIT「ページング ファイルが小さすぎるため…」）や OutOfMemoryException がクラッシュ時刻に並ぶ → コミット枯渇で確定。
• 巻き添えの有無が最重要。同時刻に PowerShell・クラッシュレポータ・OS 常駐アプリなど 無関係なプロセスも落ちていれば、原因はシステム全体の資源枯渇。単体プロセスの OOM では巻き添えは起きない。

ここで誤診しやすい2点（実際に踏んだ）

• 「落ちた当該プロセスの Application Error 記録が無い」ことを「単体 OOM の証拠」と読むのは誤り。 __fastfail は WER に faulting module を残さないので、記録が無いこと自体は何の切り分けにもならない。 faulting module が残るのは DLL 内で例外が出たケースだけ。
• LiveKernelEvent 141 と WER の BlueScreen エントリはノイズになりやすい。 前者は GPU / ディスプレイドライバのリセット（TDR）、後者はそのライブダンプ報告で、 実際のブルースクリーンではない。本当に落ちたなら System ログに Kernel-Power ID 41 か ID 6008 が残る。無ければ一度も再起動していない。 件数が多くて目を引くが（実測例: 10日で 136 件）、exit 3221226505 とは無関係な別問題として扱う。

3. コミット率を測る（90%超で危険域）

$os = Get-CimInstance Win32_OperatingSystem
$tot = $os.TotalVirtualMemorySize/1MB; $free = $os.FreeVirtualMemory/1MB
"commit: {0:N1} GB / {1:N1} GB = {2:N1}%" -f ($tot-$free), $tot, (($tot-$free)/$tot*100)
Get-CimInstance Win32_ComputerSystem | Select-Object AutomaticManagedPagefile
Get-CimInstance Win32_PageFileSetting | Select-Object Name, InitialSize, MaximumSize

• コミット上限 = 物理 RAM ＋ ページファイル。 AutomaticManagedPagefile = False（手動固定）だと、RAM をいくら増やしても上限が固定値で天井になる。
• 「pagefile の現在使用量はわずかしかない」は無視して良い。効いているのは使用量ではなく上限。

4. 消費元を特定する（WorkingSet ではなくコミットで見る）

Get-Process | Group-Object ProcessName |
  Select-Object Name, Count, @{n='GB';e={[math]::Round((($_.Group | Measure-Object PrivateMemorySize64 -Sum).Sum)/1GB,1)}} |
  Sort-Object GB -Descending | Select-Object -First 10

PrivateMemorySize64（＝コミット）で見る。予約だけで未使用のメモリも上限を食うため、 WorkingSet で見ると消費元を見落とす。

長時間動かす AI エージェント / 言語サーバ / エディタ拡張は、1セッションあたり数百 MB を常時コミットする。 セッションを閉じずに溜め込むと、これが支配的な消費元になる（実測例: エージェント 63 セッションで 28.4 GB、 1本あたり平均 461 MB。同時に動いていたブラウザ 87 プロセスより多かった）。

5. 対処（効果順）

1. ページファイルを「システム管理」に戻す（要管理者権限＋再起動）。

   Set-CimInstance -InputObject (Get-CimInstance Win32_ComputerSystem) -Property @{AutomaticManagedPagefile=$true}
   

   手動固定のままだとコミット上限が「RAM＋固定値」で天井になり、RAM 増設の効果が出ない。
2. セッションを溜めない。 1セッション ≈ 数百 MB のコミットを常時消費する。 タスク単位でセッションを閉じる運用は、トークン効率だけでなくマシンの安定性そのものに効く。 会話履歴はファイルに残るので、閉じても後から再開できる（閉じる前にそれを確認しておく）。
3. プロセスの終了は必ず PID 指定で行う。 taskkill /IM <name>.exe 型の一括 kill は 稼働中の作業を巻き添えにする。自分自身の祖先 PID を親子チェーンで辿って除外すること。

やってはいけない対処

• NODE_OPTIONS=--max-old-space-size=<大きい値> を入れる。 これはプロセス単体のヒープ上限（既定 約4.3GB）を動かす設定で、 コミット上限が縛っている状況では逆効果。1プロセスがより大きく膨らむことを許すだけで、 巻き添えの範囲を広げる。stderr に JavaScript heap out of memory が出ている場合に限って有効。

  誤って設定した場合の戻し方（setx VAR "" では値が空文字で残るため、キーごと削除する）:

  Remove-ItemProperty -Path 'HKCU:\Environment' -Name 'NODE_OPTIONS'
  

  戻ったことは新しいプロセスで実測して確認する:

  node -e "console.log(Math.round(require('v8').getHeapStatistics().heap_size_limit/1048576))"
  

6. 完了条件

• 原因を「コミット枯渇 / libuv / V8 OOM / ネイティブモジュール」のどれかに根拠付きで確定させた
• コミット率を実測し、対処後に再測して下がったことを確認した
• 「たぶんメモリ不足」で終わらせていない