Claude Desktop (Electron) causes NTFS NonPaged Pool kernel memory leak on Windows (~0.5GB/min)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
Claude Desktop causes Windows kernel NonPaged Pool to grow at ~0.5GB/min while idle
Pool tag NtFC (ntfs.sys Create.c) — 20M+ allocations, near-zero frees
Leak stops immediately when all claude.exe processes are killed
Started after updating to latest version (Cowork update)
What Should Happen?
No leak
Error Messages/Logs
Steps to Reproduce
- Install Claude Desktop on Windows 11
- Open the app (no need to chat or do anything)
- Run: "NonpagedPool: {0:N1} GB" -f ((Get-CimInstance Win32_PerfFormattedData_PerfOS_Memory).PoolNonpagedBytes / 1GB)
- Wait 5 minutes, run again
- NonPaged Pool grows ~0.5GB/min even while completely idle
- Kill all claude.exe processes — growth stops immediately
Claude Model
Opus
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
2.1.96.
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
What we ruled out:
MCP servers (disabled both, still leaks)
Cloud code execution / VM sandbox (disabled, still leaks)
Google Drive FS driver (uninstalled, still leaks)
FACEIT anti-cheat (stopped, still leaks)
Hyper-V (disabled, still leaks)
Defender (exclusions added, still leaks)
Zombie processes (none found, all processes fresh)
Handle leaks (handles stable, only +7 in 30s)
Clear cache and restart (no effect)
Root cause: Electron's file I/O pattern triggers NTFS kernel-level NtFC allocation leak. Handles open/close normally but kernel tracking entries never free. Only full PC restart clears it.
Evidence: PoolMonX screenshots showing NtFC tag dominating NonPaged Pool.
System: Windows 11, 128GB RAM, RTX 3090
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This may overlap with #43548 but adds kernel-level diagnosis: the leak is specifically pool tag NtFC (ntfs.sys Create.c) with 66M allocations vs 2K frees. Ruled out all third-party drivers — isolated to claude.exe Electron file I/O. PoolMonX evidence attached.
Independently confirmed this in #45921 with ETW tracing and kernel pool tag analysis:
.wvm-tmp-*fromclaude.exeNtFC(NTFS FCB) grows at ~13 GB/hr — math: 27K files/sec × 130 bytes × 3600s = 12.6 GB/hrAlso related: #43548
Same issue as in #45921. This isn't an annoyance, this makes running Claude Desktop a non-starter for those affected.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
This is is an issue - Non-paged pool quickly increase from 500MB to 12GB with just a few prompts
Just as a reminder, there's a proven workaround that totally fixes this behaviour: a complete cleanup of anything Anthropic/Claude related on the machine, including registry and hidden folders, then a clean reinstall and login. You want to first backup any relevant configs and data, but don't restore anything you don't need.
This has fixed the issue permanently, while the initial root cause remains anyone's guess. Something corrupt somewhere.
Additional diagnosis: leak is the Electron main process recursively scanning its virtualized AppData (not Chrome / not a watched project folder)
Reproduced on Windows 11, MSIX-packaged Claude Desktop 1.14271.0.0, 32 GB RAM. Confirming the NtFC (NTFS Create.c, nonpaged, ntoskrnl) leak and adding root-cause detail.
Measured behavior
Pool tag NtFC: millions of allocations, ~0 frees. Grew ~190 MB/min (reached 15 GB before a restart). Read via NtQuerySystemInformation(SystemPoolTagInformation=0x16).
System-wide \System\File Control Operations/sec sits at ~95,000–105,000/sec while Claude Desktop is open (normal baseline ~500/sec).
Isolation (suspend/resume tests, NtSuspendProcess)
Suspend only the Electron main process → File-Control ops drop 96,991 → 64/sec and NtFC growth → 0. Resume → returns.
Suspending the GPU process, the renderers, or all of Chrome individually → no effect.
What the main process is doing (ETW Microsoft-Windows-Kernel-File trace, 3 s)
~47,000 file opens across ~46,800 distinct paths in 3 seconds, all under the package's virtualized ...\Packages\Claude_****\LocalCache\ (redirected AppData\Local + AppData\Roaming).
A recursive enumeration / poll of the entire virtualized AppData tree, repeated continuously. Polling, not change-driven.
Ruled out (with evidence)
Third-party filesystem filters — fltmc filters shows an all-Microsoft stack.
"Claude in Chrome" / browser connector and Chrome itself — leak continues unchanged with Chrome fully closed and the connector disconnected.
Specific large project/working folders — main process holds zero handles outside AppData and the install dir.
Cache bloat — Roaming\Claude is ~340 MB / normal.
Suggested area: a recursive (likely polling) file watcher in the main process whose root is the whole user-data / AppData path rather than a specific subdirectory.
I have same problem, Claude Desktop eating my RAM!! 37Gb per 5 hours.
Any fix for that?
Windows 11, latest updates
Claude 1.15962.0 (039543) 2026-06-25T01:24:19.000Z
https://github.com/anthropics/claude-code/issues/45889#issuecomment-4701891749
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.