[BUG] Claude Desktop VM leaks ~13 GB/hr of kernel memory (NonPaged Pool) via temp file churn
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?
I attempted to report this via In-App Chat but the agent asked me to report it here, I apologize in advance if this isn't the right channel. Note: This is a Claude Desktop (not Claude Code) issue — filing here per Claude Desktop in-app support direction. Note: This is a Claude Desktop (not Claude Code) issue — filing here per Claude Desktop in-app support direction. I asked Claude Code to write this draft after thoroughly investigating the issue:
Claude Desktop for Windows causes a critical kernel memory leak that crashes the system within 2-3
hours. The embedded VM (claudevm.bundle) creates ~27,000 temporary files per second with unique
names (.wvm-tmp-XXXXXX). Each unique filename generates an NTFS File Control Block (FCB) cached in
NonPaged Pool, which is never reclaimed while the app runs.
Environment
- Product: Claude Desktop for Windows
- Version: Claude 1.1062.0 (b81bcd) 2026-04-06T21:20:28.000Z
- OS: Windows 11 Pro 10.0.26200
- RAM: 32 GB
- Install drive: NTFS volume
Root Cause Analysis
The claudevm.bundle VM creates and immediately deletes temporary files at ~27,000 files/sec. File
paths follow the pattern:
%APPDATA%\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-XXXXXX
Each unique filename causes NTFS to allocate a File Control Block (FCB) in NonPaged Pool (pool tag
NtFC, ~130 bytes each). NTFS caches these FCBs and does not reclaim them for rapidly churned unique
filenames. The math matches exactly:
▎ 27,000 files/sec × 130 bytes × 3,600 sec = 12.6 GB/hr
▎ Measured rate: 12–13 GB/hr
NonPaged Pool is unswappable kernel memory. When it fills physical RAM, Windows crashes.
Evidence
- ETW file I/O trace: 91% of all file operations originate from claude.exe
- Pool tag breakdown: NtFC accounts for 98% of NonPaged Pool growth (178.6M outstanding allocations
observed)
- Handle count mismatch: Only ~7,000 open file handles vs. 169M+ outstanding FCB allocations —
confirms files are created/deleted but FCBs are retained
- Process behavior: 12 claude.exe processes spawn on launch; 7 survive after closing the app window
(require taskkill)
- Reproduction confirmed across reboots (2026-04-07, 2026-04-08, 2026-04-09)
Impact
- Severity: Critical — causes system crash within 2-3 hours of normal use
- Scope: May affect other Windows NTFS installations running Claude Desktop
- No user workaround other than closing the app and rebooting (NonPaged Pool is only freed on
reboot)
What Should Happen?
Claude desktop VM should not create and immediately delete temporary files at ~27,000 files/sec
Error Messages/Logs
=== Claude Desktop NonPaged Pool Leak - Log Evidence ===
Date: 2026-04-08
OS: Windows 11 Pro 10.0.26200, 32 GB RAM
Tool: ETW (Event Tracing for Windows) - Microsoft-Windows-Kernel-File provider
--- ETW Trace Summary (5-second capture) ---
Files Processed:
M:\diag_tmp\fileio_trace_000001.etl
Total Buffers Processed 133
Total Events Processed 543226
Total Events Lost 0
Start Time Wednesday, April 8, 2026
End Time Wednesday, April 8, 2026
Elapsed Time 5 sec
+-------------------------------------------------------------------------------------------------------------------------+
|Event Count Event Name Task Opcode Version Guid |
+-------------------------------------------------------------------------------------------------------------------------+
| 1 EventTrace 0 PartitionInfoExtension 2 {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
| 1 EventTrace 0 Header 2 {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
| 76 Microsoft-Windows-Kernel-File 17 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 10 Microsoft-Windows-Kernel-File 32 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 17 Microsoft-Windows-Kernel-File 34 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 216 Microsoft-Windows-Kernel-File 20 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 806 Microsoft-Windows-Kernel-File 14 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 803 Microsoft-Windows-Kernel-File 13 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1393 Microsoft-Windows-Kernel-File 16 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1227 Microsoft-Windows-Kernel-File 15 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1538 Microsoft-Windows-Kernel-File 22 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1469 Microsoft-Windows-Kernel-File 23 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 414 Microsoft-Windows-Kernel-File 10 Info 0 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 263833 Microsoft-Windows-Kernel-File 12 Info 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 271387 Microsoft-Windows-Kernel-File 24 Info 0 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 35 Microsoft-Windows-Kernel-File 11 Info 0 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
+-------------------------------------------------------------------------------------------------------------------------+
+---------------------------------------------------------------------------------------------------------+
|Event Count Event Name Event ID Version Guid |
+---------------------------------------------------------------------------------------------------------+
| 2 EventTrace 0 2 {68fdd900-4a3e-11d1-84f4-0000f80464e3}|
| 414 Microsoft-Windows-Kernel-File 10 0 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 35 Microsoft-Windows-Kernel-File 11 0 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 263833 Microsoft-Windows-Kernel-File 12 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 803 Microsoft-Windows-Kernel-File 13 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 806 Microsoft-Windows-Kernel-File 14 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1227 Microsoft-Windows-Kernel-File 15 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1393 Microsoft-Windows-Kernel-File 16 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 76 Microsoft-Windows-Kernel-File 17 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 216 Microsoft-Windows-Kernel-File 20 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1538 Microsoft-Windows-Kernel-File 22 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 1469 Microsoft-Windows-Kernel-File 23 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 271387 Microsoft-Windows-Kernel-File 24 0 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 10 Microsoft-Windows-Kernel-File 32 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
| 17 Microsoft-Windows-Kernel-File 34 1 {edd08927-9cc4-4e65-b970-c2560fb5c289}|
+---------------------------------------------------------------------------------------------------------+
--- Key Stats ---
Total file I/O events in 5-sec trace: 543,226
Events targeting .wvm-tmp-* files: 262,928 (97% of file create/close events)
Source process: claude.exe (PID 33520)
File path pattern: \Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-XXXXXX
Each temp filename is unique (random 6-char suffix), created and deleted within <1ms.
Rate: ~27,000 unique temp files/sec × 130 bytes NTFS FCB = ~12.6 GB/hr NonPaged Pool growth.
--- Sample ETW Events (first 30 .wvm-tmp file creates, Event ID 12 = CreateNewFile) ---
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725610277, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CA99A0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-F8bSkM"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725610597, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAF5D0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-F8bSkM"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725611118, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAEAE0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-DwLL7u"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725611421, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CABC00, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-DwLL7u"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725611824, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAC0B0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-SbUc4z"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725612081, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CACA10, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-SbUc4z"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725612501, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CADE60, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-iQYcdp"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725612943, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAEE00, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-iQYcdp"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725613353, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAE4A0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-2rMDXk"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725613563, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAC880, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-2rMDXk"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725613830, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAADF0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-VDCESs"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725613985, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CADB40, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-VDCESs"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725614226, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAF440, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-am3Dhn"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725614376, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAFC10, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-am3Dhn"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725614603, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CABD90, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-Q2zv79"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725614747, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAC6F0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-Q2zv79"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725614968, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAC560, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-RiDorx"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725615114, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAF8F0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-RiDorx"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725615344, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAA490, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-w16bCC"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725615495, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAC240, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-w16bCC"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725615715, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CACD30, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-iQP2Fn"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725615859, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAA940, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-iQP2Fn"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725616090, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAA7B0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-7Cwg0k"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725616237, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAAC60, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-7Cwg0k"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725616461, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CACEC0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-eGzILt"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725616608, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAA620, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-eGzILt"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725616828, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAD690, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-IZuPWc"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725616979, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAB430, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-IZuPWc"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725617212, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAA170, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Local\Packages\Claude_pzs8sxrjxfjjc\LocalCache\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-82jrB2"
Microsoft-Windows-Kernel-File , Info , 12, 1, 16, 4, 0, 12, 0x00000000000000A0, 0x000082F0, 0x00008D78, 0, , , {00000000-0000-0000-0000-000000000000}, , 134201821725617363, 6879345, 330975, 0xFFFFC002271F80F8, 0xFFFFC00174CAB2A0, 36216, 0x1000000, 0x0, 0x7, "\Device\HarddiskVolume7\Users\<user>\AppData\Roaming\Claude\vm_bundles\claudevm.bundle\.wvm-tmp-82jrB2"
--- Unique temp filenames from above sample ---
.wvm-tmp-2rMDXk
.wvm-tmp-7Cwg0k
.wvm-tmp-82jrB2
.wvm-tmp-am3Dhn
.wvm-tmp-ayoX2v
.wvm-tmp-cGPCpq
.wvm-tmp-DH6hvM
.wvm-tmp-DwLL7u
.wvm-tmp-E6E1DG
.wvm-tmp-eGzILt
.wvm-tmp-F8bSkM
.wvm-tmp-FDZzd3
.wvm-tmp-H8lfoV
.wvm-tmp-hXc5uU
.wvm-tmp-iQP2Fn
.wvm-tmp-iQYcdp
.wvm-tmp-IZuPWc
.wvm-tmp-lYgRhr
.wvm-tmp-lYRzEq
.wvm-tmp-okLPiP
.wvm-tmp-Q2zv79
.wvm-tmp-RiDorx
.wvm-tmp-rl6WQz
.wvm-tmp-SbUc4z
.wvm-tmp-tTOutJ
.wvm-tmp-uzBMWt
.wvm-tmp-VDCESs
.wvm-tmp-w16bCC
.wvm-tmp-W8Jt1R
.wvm-tmp-ZaQjoW
--- Pool Tag Evidence (captured via NtQuerySystemInformation) ---
After ~2 hours of Claude Desktop running:
Pool Tag: NtFC (NTFS File Control Block)
NonPaged Pool usage: 21.8 GB (of 32 GB physical RAM)
Outstanding allocations: 178,600,000+
Open file handles: ~7,000 (FCBs are cached, not freed)
--- Reproduction (2026-04-09, clean reboot) ---
Before Claude Desktop: NtFC not in top 30 pool consumers, 23 GB free RAM
After Claude Desktop: NtFC at 21.8 GB, only 2.5 GB free, system near crash
12 claude.exe processes spawned; 7 survived after closing app window
--- Monitor Script Output Pattern ---
Time NtFC (MB) Allocs Outstanding Rate (GB/hr)
HH:MM:SS 1,200.0 N,NNN,NNN N,NNN,NNN 12.80
HH:MM:SS 3,400.0 N,NNN,NNN N,NNN,NNN 13.20
HH:MM:SS 5,600.0 N,NNN,NNN N,NNN,NNN 12.90
[closes Claude Desktop]
HH:MM:SS 5,600.1 N,NNN,NNN N,NNN,NNN 0.01 << LEAK STOPPED!
=== End of log sample ===
Steps to Reproduce
- Reboot Windows (clean slate — NonPaged Pool starts near baseline)
- Open Claude Desktop
- Monitor NonPaged Pool usage via RAMMap, poolmon, or a NtQuerySystemInformation-based tool — look
for the NtFC pool tag
- Observe NtFC growing at ~200 MB/min (~13 GB/hr)
- Within 2-3 hours, system becomes unresponsive or blue-screens as NonPaged Pool exhausts physical
RAM
Claude Model
Sonnet (default)
Is this a regression?
Yes, this worked in a previous version
Last Working Version
_No response_
Claude Code Version
Claude 1.1062.0 (b81bcd) 2026-04-06T21:20:28.000Z
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Windows Terminal
Additional Information
Suggested Fix
Reduce or eliminate the temp file churn in claudevm.bundle. Options:
- Reuse a fixed set of temp filenames instead of generating unique names per operation
- Use a tmpfs/ramdisk within the VM instead of the host filesystem
- Batch operations to reduce file creation rate
For any additional information you may need please let me know and I will provide it or tell me if I should be reporting this elsewhere.
17 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Related issues — same root cause (claudevm.bundle temp file churn → NTFS NonPaged Pool leak):
All three reports independently identify the same mechanism:
claudevm.bundlecreating ~27K unique.wvm-tmp-*files/sec, exhausting NonPaged Pool via cached NTFS FCBs. This issue includes ETW trace evidence and pool tag math confirming the rate.Been hunting the same first as a WSL, then Cowork and then MCP issue. I have extensive logs supporting your findings. So frustrated, I have a dedicated project in Claude just to hunt what made my laptop unusable, including monitoring scripts launching at boot.
So far, conclusion is that we have two bugs in Claude Desktop: zombie processes after Quit, plus NtFC kernel pool leak. Both reproducible. Both Anthropic’s.
Correct, some processes continue in the background despite quitting Claude Desktop and they perpetuate the NP leak.
Independent reproduction with extended-duration evidence
Hitting the same bug on a different Windows 11 machine. Adding this in case longer-window data and connector-state variations help triage.
Environment: Windows 11, 32 GB RAM, NTFS install drive, Claude Desktop 1.5354.0.0 (MSIX install)
Symptom match: identical to the original report.
NtFCtag dominates non-paged pool growth (92-94% of measured increase across multiple captures). 10-12claude.exeprocesses spawn on launch, 7 survive after "Quit" from tray and require force-kill. Killing allclaude.exeprocesses stops growth immediately; pool damage persists until reboot.Observed rates across multiple sessions:
Per-process attribution confirms kernel-side accumulation:
99.9% of non-paged pool is unattributable to any process. Matches the FCB-cached-but-no-handle pattern in the original report.
Connector-state observations (may be useful for narrowing the trigger):
CoworkVMServicevia Autoruns reduced leak rate substantially but did not eliminate it — Claude Desktop still leaks at multi-GB/hour with the service stopped/disabled, suggestingclaudevm.bundleactivity happens independent of the Cowork service.node.exerunning the MCP server) survive the toggle and must be killed manually.Same-boot A/B reproducer:
| Phase | Duration | NonPaged delta |
|---|---|---|
| Idle (browsers + Edge background, Cowork disabled) | 4 hours | +76 MB |
| Claude Desktop launch | ~3 min | +149 MB (one-time startup) |
| Claude Desktop active use | 5 min | +970 MB |
| All
claude.exeprocesses killed | 2 min | +0 MB (plateau) |Diagnostic tooling: built a continuous background monitor that captures
\Memory\Pool Nonpaged Bytesplus top-3 poolmon tags every minute, with burst-detection auto-triggering deeper poolmon/process/fltmc captures. Happy to share CSV/JSON data, ETW captures, or the monitor scripts if useful for triage. Multi-day, multi-boot data available with timestamps aligned to specific user actions.Workaround in use: Claude.ai web app for daily work, Claude Desktop only when MCP filesystem access is genuinely needed, with explicit force-kill of all
claude.exeprocesses and reboot on a schedule.The original report's root cause analysis (27k unique temp files/sec in
claudevm.bundle) lines up with the rate math observed here. Suggested fixes in the original report (reuse temp names, in-memory FS within the VM, batch operations) all look reasonable from this end.Follow-up: process-tree tracking pinpoints where the Quit handler fails
Building on the surviving-processes observation in the original report (12 spawn, 7 survive Quit), I instrumented a polling process-tree tracker that logs every START/EXIT event for
claude.exeand any descendant. Ran a clean reboot, started the tracker, launched Claude Desktop, used it briefly, and Quit from the tray.Launch (14:08:11–14:08:17): 12 processes spawned, all parented directly or transitively to the Electron main process (PID 11368).
Quit (14:10:06): 5 processes exited cleanly within ~150 ms of each other. 7 survived.
Cleanly exited on Quit:
| PID | Name | Notes |
|-------|-------------|--------------------------------------|
| 17880 | claude.exe | renderer (closed via own handler) |
| 4376 | claude.exe | renderer |
| 10492 | claude.exe | renderer |
| 15776 | node.exe | MCP server child |
| 2132 | conhost.exe | console host for the MCP server |
Survived Quit (the zombies):
| PID | Name | Role |
|-------|------------|-----------------------------------------|
| 11368 | claude.exe | Electron main process |
| 9688 | claude.exe | renderer/utility |
| 20456 | claude.exe | renderer/utility |
| 14124 | claude.exe | renderer/utility |
| 3320 | claude.exe | renderer/utility |
| 9828 | claude.exe | renderer/utility |
| 2364 | claude.exe | renderer/utility |
Diagnostic conclusion
The Electron main process is among the survivors. Some children have their own Close handlers that fire on Quit (which is why renderer 17880, the MCP server, and its conhost exit), but the main process itself never processes the Quit signal and therefore never propagates app shutdown to its remaining children.
I confirmed earlier (separate test) that
Stop-Process -Id <main_pid> -Forcecleanly cascades teardown to all 7 zombies via the Windows job object. So the job object configuration is correct — process teardown works when the main process exits. The bug is localised to:Common Electron causes worth checking:
before-quitlistener callingevent.preventDefault()without a corresponding genuine-quit code pathmainWindow.hide()) instead of quittingbeforeunloadhandler that's preventing window close, leaving main waiting indefinitelyMinimal reproduction
claude.exeprocesses (≈12 expected)This is independently reproducible and not user-data dependent — it happens on a fresh boot with no prior state.
Why this matters for the NtFC leak
Surviving zombies continue running
claudevm.bundleactivity, so the temp-file churn (and corresponding NtFC pool growth) continues after the user has "quit" the app. A user who launches and quits Claude Desktop multiple times in a session accumulates increasingly many process trees, each contributing to the leak. Fixing the Quit handler would substantially reduce real-world severity of the kernel pool leak even before the underlying temp-file-churn bug is fixed.Tracker script and raw event logs available if useful — happy to share.
A complete uninstall (GUI + manual cleanup of AppData\Roaming\Claude, AppData\Local\Packages\Claude_*, registry under HKCU\Software\Anthropic, etc, leftover scheduled tasks) followed by reinstall reduced leak rate from multi-GB/hour to <50 MB over 6 minutes (essentially zero) on the same hardware. Suggests accumulated state contributes substantially to the catastrophic severity. The underlying claudevm.bundle churn likely still occurs but doesn't escalate to FCB pinning at the same rate on a fresh install.
Follow-up: complete uninstall + reinstall reduces leak rate by 100-500x on same hardware
Tested whether accumulated state contributes to the catastrophic severity. Result: yes, substantially.
Procedure:
$env:APPDATA\Claude$env:LOCALAPPDATA\Packages\Claude_*HKCU:\Software\Anthropic,HKLM:\Software\AnthropicClaude|Cowork|AnthropicGet-AppxProvisionedPackageremovalResults, same hardware (Lenovo X1, Win11, 32 GB RAM, Hyper-V + Sandbox enabled):
| Configuration | NonPaged growth rate |
|---|---|
| Old install, Cowork enabled | 6,000 - 19,000 MB/hour |
| Old install, Cowork disabled via Autoruns | ~3,000 MB/hour during active use |
| Old install, idle (no Claude Desktop) | ~19 MB/hour (baseline noise) |
| Fresh install, Cowork enabled, no MCP | ~27 MB/hour |
| Fresh install, Cowork enabled, full MCP load (Filesystem + SecurityScorecard + skills) | ~37 MB/hour |
| Hyper-V VM with fresh Claude Desktop install | similar bounded behaviour (<300 MB total) |
Measurement: continuous background monitor sampling
\Memory\Pool Nonpaged Bytesplus top poolmon tags every 60s, with burst-detection auto-triggering deep poolmon/process/fltmc captures. 4+ hours of active usage on the fresh install with full MCP load produced +160 MB total — within normal background variation.Diagnostic conclusion:
The underlying
claudevm.bundletemp-file churn (per the original report) appears to still occur on a fresh install, but does not produce catastrophic FCB retention rates. Something about the cumulative state on a long-used install (months of usage, multiple Claude Desktop versions, Cowork experimentation, MCP server additions/removals) reaches a configuration where the same churn produces unbounded FCB pinning at multi-GB/hour rates. Specific mechanism unknown — could be registry state, MSIX package state, scheduled task accumulation, or minifilter context bindings that survive normal upgrades.This also rules out several earlier hypotheses on the same machine:
CoworkVMServiceenabled and active runs at ~27 MB/hourwcifsminifilter attached to C: is not sufficient by itself — samefltmc instancesoutput between catastrophic-leak old install and benign fresh install (Sandbox + Hyper-V both enabled in both cases,wcifsattached in both cases)User-facing workaround for users hitting the catastrophic version:
Complete uninstall + manual cleanup + reinstall, as documented above. Restores normal behaviour without requiring Windows reinstall. Whether the pathological state recurs over time is unknown; will continue to monitor.
The underlying bug per #45921 remains worth fixing — fresh installs still leak at ~30-40 MB/hour above what the same machine does without Claude Desktop running, just at non-catastrophic rates. But this finding gives existing affected users a path to usable behaviour while waiting for an upstream fix.
+1, reproducing this on Windows 11 25H2 (Build 26200.8246), 16 GB RAM.
NtFC pool tag grows ~80-200 MB per 15 min of Claude Code usage
(auditing a codebase). FCBs are NOT released after closing
Claude Desktop — confirmed via PoolMonX (Diff stays at 3.6M+
allocations even after killing all claude.exe processes).
Confirmed it's not a third-party driver: tested with Defender
real-time disabled, and detached UCPD, gameflt, Wof minifilters.
NtFC keeps growing only when Claude Code is processing files.
System becomes laggy with short freezes once NonPaged Pool
exceeds ~1.5 GB. Reboot is the only way to recover.
<img width="813" height="151" alt="Image" src="https://github.com/user-attachments/assets/bfa109d4-67a9-4c38-93f6-fadd37bd048a" />
To be pragmatic. This seems like something that happening over time. What goes wrong, seems we're all just guessing.
Anthropic could fix this in two brutal but alternative ways.
+1 — Same NonPaged Pool exhaustion on Windows 11
Confirming OP's report. Setup: i7-13700KF / 32 GB / RTX 4080 / Windows 11.
Within ~30 minutes of completely idle Claude Desktop (app open, no active conversation, just sitting there), system memory hit 96% (30.6 / 31.8 GB), with NonPaged Pool at 22.3 GB — exactly the FCB retention pattern OP documents. Process view shows nothing user-mode accounting for the consumption; largest user-mode process is Chrome at ~1.5 GB. The leak is entirely kernel-side.
I do have several stdio MCP servers configured, but the leak progresses even when the app is sitting idle with no active turns.
Killing all
claude*processes viaStop-Process -Forcedoes NOT release the NonPaged Pool. Only a full OS reboot reclaims it. This is consistent with NTFS FCB allocations being retained in kernel memory independent of process lifetime.Re: the
invalidlabel — Claude Desktop's in-app support directs bug reports to this repo. Closing as "not Claude Code" without routing this elsewhere leaves users with no escalation path, despite the extensive ETW kernel evidence OP provided.Same root cause surfaces in:
claude.exe13+ GB, "NonPaged Pool leak requires reboot"Please reopen and route to the Desktop team.
@QithYang to get your personal issues resolved, I suggest a backup of key config files, an uninstall following a total cleanup of any Anthropic/ Claude files on your system (including registry).
Then download a new setup file, install and log into your account.
Cured my problems permanently but doesn't address the root cause.
Confirming same issue on Windows 11 26200.8457 (KB5089549)
Identical symptom pattern. 10+ BSODs over 24 days (May 1 ~ May 24, 2026).
WinDbg
!analyze -voutputKey observations
0x50 PAGE_FAULT_IN_NONPAGED_AREAatNtfs.sys+0xACF2(NtfsInitializeIrpContextInternal)gdrv3.sysas a partial trigger (0xC4 violations on the same workload) — disabling gdrv3 + uninstalling GIGABYTE Control Center reduced but did NOT eliminate the Ntfs.sys BSODEnvironment
cbfltfs4(EldoS Callback File System, appears to be Cowork-related)Workarounds attempted (none fully effective)
/RestoreHealth: cleansc delete+start= disabled/scan: 0 bad sectorsRequest
Cowork launch reliably triggers Ntfs.sys NULL pointer dereference within 1-2 hours on this machine. The
NtfsInitializeIrpContextInternal+0xACF2signature appears consistent across all dumps and aligns with the file-system-filter callback pattern described in #30137.Reporting from Korea — several Korean users report similar pattern but in fragmented forum posts. Consolidating here.
Full MEMORY.DMP (34 GB) and 10 minidumps available if Anthropic engineering wants them.
Another reproduction — same leak on lower-spec hardware (16 GB)
Every time Cowork launches, non-paged pool grows steadily to ~9 GB (of 16 GB physical RAM), fans max out, the system hangs, and only a full reboot reclaims the memory. Reproduced consistently for weeks.
Already ruled out: GPU driver updates, switching from Intel UHD to NVIDIA dGPU, disabling the Intel UHD adapter, full uninstall/reinstall — no effect, consistent with the NTFS FCB /
NtFCtemp-file churn described above rather than anything hardware-related.On 16 GB machines this makes Cowork effectively unusable within a single session. (Note: #48813 covering the same symptom was closed as not planned — this issue appears to be the active tracker.)
Confirmation + additional data: NonPaged Pool (NtFC) leak crashes Windows — re #45921
Summary
Independent reproduction of the
NtFC(NTFS File Control Block) NonPaged Pool leak described in#45921. On a 32 GB machine the NonPaged Pool grew until physical RAM and the commit limit were
exhausted, the system became unresponsive, and a hard reboot was required. The
NtFCpool tagaccounted for essentially the entire NonPaged Pool, with ~184 million outstanding allocations and
almost no frees — consistent with high-rate unique-temp-file churn from the Claude Desktop VM
(
claudevm.bundle).Environment
Symptoms / Impact
user-space process** accounting for it (Process Private was normal, ~2.9 GB).
the app, which is why the leak is invisible in per-process views.
Evidence
RAMMap (Use Counts, during the leak)
| Category | Active |
|-----------------|-------------------|
| Nonpaged Pool | 27,931,328 KB (~26.6 GiB) |
| Process Private | 3,040,864 KB (~2.9 GiB) — normal |
| Total Active | 33,124,336 KB (~31.6 GiB of 32 GB) |
| Available | a few hundred KB (essentially exhausted) |
A healthy baseline snapshot taken right after reboot showed Nonpaged Pool at ~344 MB — i.e. the
pool had grown roughly 80×.
poolmon (sorted by Bytes,
B; NonPaged,P)System header at time of capture:
Top pool tag:
NtFC= NTFS File Control Block, NonPaged.never released.
Diagnostic path (for reproducibility)
Use Counts: identified NonPaged Pool as the consumer (not any process).poolmon.exe, pressedP(NonPaged) thenB(sort by bytes):NtFCat top.NtFCmaps to NTFS FCB allocations (FsRtl pool tag).claudevm.bundlecreating/deleting unique.wvm-tmp-XXXXXXfiles athigh rate, each generating an FCB that NTFS caches and does not reclaim during churn.
Filed a fresh fully-instrumented report of this leak as #67819 (two complete 32 GB RAM-exhaustion cycles in under 4 hours, NtFC time series from 30-min pool-tag snapshots, growth 12-16.5 GB/h, Claude Desktop 2.1.161 / Win11 26200.8655) — since this issue carries an
invalidlabel and has had no maintainer response, please re-triage there.Confirmed reproduction on Windows 11 25H2 — controlled on/off test with NtFC pool tag measurement
Summary
I can confirm the exact same
NtFCnonpaged pool leak described in this issue. I ran a controlled on/off comparison usingNtQuerySystemInformation(SystemPoolTagInformation)to measure the pool tag directly, eliminating any ambiguity.Result:
| State | NtFC leak rate |
|-------|---------------|
| Claude Desktop running (9 processes) | 7.34 MB/s (~25.8 GB/hr) |
| Claude Desktop killed (all
WindowsApps\Claude_*PIDs stopped) | 0.00 MB/s (complete stop) |The leak stops immediately and completely when Claude Desktop processes are terminated. NtFC does not drop instantly (FCBs stay cached), but the growth rate goes to zero within seconds of killing the processes.
Environment
1.12603.1.0(packageClaude_1.12603.1.0_x64__pzs8sxrjxfjjc)Symptom timeline
This matches the ~12–13 GB/hr rate in the original report (my system measures ~25.8 GB/hr, possibly due to different hardware or Desktop version).
Test methodology
Stage 1 (Desktop running, 9 processes, 60-second window):
Stage 2: Killed all PIDs matching
*WindowsApps\Claude_*(9 processes). Noclaude-codeornode.exeprocesses were touched.Stage 3 (Desktop killed, 90-second window):
What I ruled out before finding this
vgk.sys) — disabled at boot (confirmedStart=4, service Stopped); NtFC continued at ~7.7 MB/s. Eliminated.iaStorVD.sys/ Micronmtihint.sys— never got to test; the Claude Desktop on/off test was conclusive.Workaround
Fully quitting Claude Desktop (not just minimizing) stops the leak immediately. A machine reboot clears the accumulated NtFC.
Setting pagefile to a fixed maximum (e.g. 4096–8192 MB) prevents C: drive exhaustion in the meantime, at the cost of potential OOM kills if the leak runs long enough.
Request
Please investigate
claudevm.bundlefile churn on Windows — specifically whether the VM creates large numbers of uniquely-named temporary files (e.g..wvm-tmp-XXXXXX) that cause NTFS to accumulate File Control Blocks (NtFC) in nonpaged pool without releasing them after file deletion. An ETW file I/O trace or a fix to reuse temp file names (or use a RAM-backed FS) would be the right diagnostic/fix direction.