# Windows で AI エージェント / Node プロセスが `exit code 3221226505` で突然死する時の診断手順 `Error: 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. イベントログ（決定的な手がかり） ```powershell 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%超で危険域） ```powershell $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 ではなくコミットで見る） ```powershell 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. **ページファイルを「システム管理」に戻す**（要管理者権限＋再起動）。 ```powershell Set-CimInstance -InputObject (Get-CimInstance Win32_ComputerSystem) -Property @{AutomaticManagedPagefile=$true} ``` 手動固定のままだとコミット上限が「RAM＋固定値」で天井になり、RAM 増設の効果が出ない。 2. **セッションを溜めない。** 1セッション ≈ 数百 MB のコミットを常時消費する。 タスク単位でセッションを閉じる運用は、トークン効率だけでなく**マシンの安定性そのもの**に効く。 会話履歴はファイルに残るので、閉じても後から再開できる（閉じる前にそれを確認しておく）。 3. **プロセスの終了は必ず PID 指定で行う。** `taskkill /IM .exe` 型の一括 kill は 稼働中の作業を巻き添えにする。自分自身の祖先 PID を親子チェーンで辿って除外すること。 ### やってはいけない対処 - **`NODE_OPTIONS=--max-old-space-size=<大きい値>` を入れる。** これはプロセス単体のヒープ上限（既定 約4.3GB）を動かす設定で、 **コミット上限が縛っている状況では逆効果**。1プロセスがより大きく膨らむことを許すだけで、 巻き添えの範囲を広げる。stderr に `JavaScript heap out of memory` が出ている場合に限って有効。 誤って設定した場合の戻し方（`setx VAR ""` では値が空文字で残るため、キーごと削除する）: ```powershell Remove-ItemProperty -Path 'HKCU:\Environment' -Name 'NODE_OPTIONS' ``` 戻ったことは**新しいプロセスで実測して確認する**: ```powershell node -e "console.log(Math.round(require('v8').getHeapStatistics().heap_size_limit/1048576))" ``` ## 6. 完了条件 - 原因を「コミット枯渇 / libuv / V8 OOM / ネイティブモジュール」のどれかに**根拠付きで**確定させた - コミット率を実測し、対処後に再測して下がったことを確認した - 「たぶんメモリ不足」で終わらせていない ---