[BUG] Claude Desktop VM leaks ~13 GB/hr of kernel memory (NonPaged Pool) via temp file churn

Open 💬 17 comments Opened Apr 9, 2026 by lizergic

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

  1. Reboot Windows (clean slate — NonPaged Pool starts near baseline)
  2. Open Claude Desktop
  3. Monitor NonPaged Pool usage via RAMMap, poolmon, or a NtQuerySystemInformation-based tool — look

for the NtFC pool tag

  1. Observe NtFC growing at ~200 MB/min (~13 GB/hr)
  2. 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.

View original on GitHub ↗

17 Comments

github-actions[bot] · 3 months ago

Found 2 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/45889
  2. https://github.com/anthropics/claude-code/issues/43548

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

lizergic · 3 months ago

Related issues — same root cause (claudevm.bundle temp file churn → NTFS NonPaged Pool leak):

  • #45889 — Claude Desktop (Electron) causes NTFS NonPaged Pool kernel memory leak on Windows (~0.5GB/min)
  • #43548 — Claude Desktop App (Windows): Extreme "Other" I/O rate causes kernel nonpaged pool exhaustion

All three reports independently identify the same mechanism: claudevm.bundle creating ~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.

CallMarcus · 2 months ago

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.

lizergic · 2 months ago

Correct, some processes continue in the background despite quitting Claude Desktop and they perpetuate the NP leak.

CallMarcus · 2 months ago

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. NtFC tag dominates non-paged pool growth (92-94% of measured increase across multiple captures). 10-12 claude.exe processes spawn on launch, 7 survive after "Quit" from tray and require force-kill. Killing all claude.exe processes stops growth immediately; pool damage persists until reboot.

Observed rates across multiple sessions:

  • Mid-session active use: 6-19 GB/hour
  • Peak burst phase: ~1 GB per 5-minute window sustained
  • Worst single-boot accumulation: 21 GB non-paged before forced reboot

Per-process attribution confirms kernel-side accumulation:

Top processes by NPM after ~7 hours of leak:
vmmemCmZygote   7.39 MB
winlogon        1.26 MB
MsMpEng         0.24 MB
[everything else <0.15 MB]
Total user-mode NPM: <10 MB
Host non-paged pool: 8.5+ GB

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):

  1. Disabling CoworkVMService via Autoruns reduced leak rate substantially but did not eliminate it — Claude Desktop still leaks at multi-GB/hour with the service stopped/disabled, suggesting claudevm.bundle activity happens independent of the Cowork service.
  2. Toggling MCP connectors (Filesystem, Microsoft 365, etc.) off in the UI does not stop the leak. Spawned MCP server child processes (node.exe running the MCP server) survive the toggle and must be killed manually.
  3. Browser-based Claude.ai shows no leak. 4-hour idle test on the same boot, same connectors enabled in account, browsers running: 631 MB → 707 MB non-paged drift (normal Windows variance). Switching from browser to Claude Desktop on the same conversation immediately resumed the leak at ~340 MB/min.

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.exe processes killed | 2 min | +0 MB (plateau) |

Diagnostic tooling: built a continuous background monitor that captures \Memory\Pool Nonpaged Bytes plus 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.exe processes 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.

CallMarcus · 2 months ago

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.exe and 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> -Force cleanly 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:

The Quit menu action in the main process is not triggering app shutdown (app.quit() or equivalent).

Common Electron causes worth checking:

  1. A before-quit listener calling event.preventDefault() without a corresponding genuine-quit code path
  2. The Quit handler hiding the window (mainWindow.hide()) instead of quitting
  3. A renderer with a beforeunload handler that's preventing window close, leaving main waiting indefinitely
  4. The main process is waiting on a renderer-confirmation IPC that never arrives

Minimal reproduction

  1. Launch Claude Desktop on Windows
  2. Open Task Manager → Details, count claude.exe processes (≈12 expected)
  3. Quit from system tray icon
  4. Count again — should be 0, will be 7

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.bundle activity, 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.

CallMarcus · 2 months ago

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.

CallMarcus · 2 months ago

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:

  1. GUI uninstall via Settings → Apps
  2. Reboot
  3. Manual cleanup of residual state:
  • $env:APPDATA\Claude
  • $env:LOCALAPPDATA\Packages\Claude_*
  • HKCU:\Software\Anthropic, HKLM:\Software\Anthropic
  • Scheduled tasks matching Claude|Cowork|Anthropic
  • Get-AppxProvisionedPackage removal
  1. Reboot
  2. Fresh install from claude.ai/download (same version: 1.5354.0.0)
  3. Sign in, configure MCP servers, use normally

Results, 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 Bytes plus 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.bundle temp-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:

  • MCP Filesystem connector is not the trigger — fresh install with Filesystem connector active runs at ~37 MB/hour
  • Cowork service running is not the trigger — fresh install with CoworkVMService enabled and active runs at ~27 MB/hour
  • wcifs minifilter attached to C: is not sufficient by itself — same fltmc instances output between catastrophic-leak old install and benign fresh install (Sandbox + Hyper-V both enabled in both cases, wcifs attached 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.

Rykuvi · 2 months ago

+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" />

CallMarcus · 2 months ago

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.

  • Provide a supported uninstaller that backs up critical local configurations but wipes literally everything created or generated by the Claude current and past versions of Claude Desktop and anything it might store.
  • find what's actually braking on these cases and create a routine bundled with updates that fixes this.
QithYang · 2 months ago

+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 via Stop-Process -Force does 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 invalid label — 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:

  • #42169 — claude.exe 13+ GB, "NonPaged Pool leak requires reboot"
  • #42962 — Desktop leaks ~6% RAM/4 min while idle
  • #30137 — Ntfs.sys kernel BSOD during Claude sessions

Please reopen and route to the Desktop team.

CallMarcus · 2 months ago

@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.

kyb8801 · 1 month ago

Confirming same issue on Windows 11 26200.8457 (KB5089549)

Identical symptom pattern. 10+ BSODs over 24 days (May 1 ~ May 24, 2026).

WinDbg !analyze -v output

FAILURE_BUCKET_ID:  AV_Ntfs!NtfsInitializeIrpContextInternal
MODULE_NAME: Ntfs
IMAGE_VERSION: 10.0.26100.8328
Failure.Exception.IP.Offset: 0xacf2
Failure.Hash: {10e0443b-e3dc-2b30-8597-cf655d6bbbf0}
Hypervisor.RootFlags.IsHyperV: 1

Key observations

  • All 10 BSODs share identical signature: 0x50 PAGE_FAULT_IN_NONPAGED_AREA at Ntfs.sys+0xACF2 (NtfsInitializeIrpContextInternal)
  • BSOD reproducible within 1-2 hours of Cowork launch, sometimes within minutes
  • Pool Watchdog 26h trace: NonPaged Pool stays 0.36~0.55 GB on this system — NtFC pool leak NOT reproduced here (different mechanism but same end-result BSOD as #45921)
  • Driver Verifier identified GIGABYTE gdrv3.sys as a partial trigger (0xC4 violations on the same workload) — disabling gdrv3 + uninstalling GIGABYTE Control Center reduced but did NOT eliminate the Ntfs.sys BSOD
  • BSOD continues after Tachyon/AhnLab/nProtect drivers disabled, GCC fully removed, SFC/DISM clean, chkdsk clean, RAM diag clean, NVIDIA driver verified

Environment

  • Windows 11 Pro 26200.8457
  • GIGABYTE motherboard (B760/Z790-class)
  • Intel CPU, 32 GB RAM, Samsung NVMe
  • Hyper-V + VBS active (required by Cowork)
  • File system filter chain includes cbfltfs4 (EldoS Callback File System, appears to be Cowork-related)

Workarounds attempted (none fully effective)

  • SFC + DISM /RestoreHealth: clean
  • Tachyon / AhnLab / nProtect drivers sc delete + start= disabled
  • GIGABYTE Control Center / RGB Fusion / EasyTune / Storage Library all uninstalled
  • Cowork 2h auto-restart (Task Scheduler) + NonPaged Pool watchdog (custom PowerShell)
  • chkdsk /scan: 0 bad sectors
  • Windows Memory Diagnostic: clean

Request

Cowork launch reliably triggers Ntfs.sys NULL pointer dereference within 1-2 hours on this machine. The NtfsInitializeIrpContextInternal+0xACF2 signature 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.

tingjunxien1 · 1 month ago

Another reproduction — same leak on lower-spec hardware (16 GB)

  • Device: HP ENVY Laptop 15-ep0xxx, Intel i5-10300H, 16 GB RAM, NVIDIA GTX 1650 Ti
  • OS: Windows 11 Home 25H2 (build 26200.8524)
  • Claude Desktop: latest version (reinstalled multiple times)

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 / NtFC temp-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.)

Dezeter · 1 month ago

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 NtFC pool tag
accounted 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

  • Product: Claude Desktop for Windows
  • Version: Claude 1.11847.5 (9692f0) 2026-06-09T17:34:27.000Z
  • OS: Windows 11 Pro 24H2 26100.8655
  • RAM: 32 GB
  • Install drive: NTFS volume

Symptoms / Impact

  • Over several hours of uptime, Task Manager reported memory usage climbing toward 100% with **no

user-space process** accounting for it (Process Private was normal, ~2.9 GB).

  • Disk simultaneously pegged at 100% (page-file thrashing as physical RAM was exhausted).
  • System became unresponsive; only a reboot recovered the memory.
  • NonPaged Pool is unswappable kernel memory — it is only reclaimed on reboot, not by closing

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:

Memory: 33,415,220K   Avail: 343,412K     (~335 MB free of 32 GB)
Commit: 45,772,968K   Limit: 46,522,416K   Peak: 46,522,416K   (commit peaked AT the limit)
Pool   N: 27,490,200K   P: 493,780K

Top pool tag:

Tag    Type   Allocs        Frees     Diff           Bytes            Per Alloc
NtFC   Nonp   183,897,177   578       183,896,599    26,481,110,256   144
  • NtFC = NTFS File Control Block, NonPaged.
  • ~183.9M outstanding allocations, only 578 frees → allocations are created and effectively

never released.

  • ~24.7 GiB in this single tag — ~95% of the entire NonPaged Pool.
  • 144 bytes per allocation, matching the FCB-per-unique-filename pattern in #45921.

Diagnostic path (for reproducibility)

  1. RAMMap → Use Counts: identified NonPaged Pool as the consumer (not any process).
  2. Installed WDK → poolmon.exe, pressed P (NonPaged) then B (sort by bytes): NtFC at top.
  3. Confirmed tag NtFC maps to NTFS FCB allocations (FsRtl pool tag).
  4. Behavior matches #45921: claudevm.bundle creating/deleting unique .wvm-tmp-XXXXXX files at

high rate, each generating an FCB that NTFS caches and does not reclaim during churn.

siaochuan · 1 month ago

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 invalid label and has had no maintainer response, please re-triage there.

TONwisdomyang · 1 month ago

Confirmed reproduction on Windows 11 25H2 — controlled on/off test with NtFC pool tag measurement

Summary

I can confirm the exact same NtFC nonpaged pool leak described in this issue. I ran a controlled on/off comparison using NtQuerySystemInformation(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

  • OS: Windows 11 Home 25H2, Build 26200.8655 (KB5094126, installed 2026-06-10)
  • CPU: Intel Core i7-14700K (20 cores / 28 logical processors)
  • RAM: 64 GB
  • Storage: Micron CT1000P3PSSD8 1 TB NVMe SSD (single drive, C: only)
  • Motherboard: ASUS PRIME B760M-A WIFI D4
  • Claude Desktop version: 1.12603.1.0 (package Claude_1.12603.1.0_x64__pzs8sxrjxfjjc)

Symptom timeline

  • At boot: C: drive has ~30 GB free, NtFC ~0 GB
  • After 2–3 hours with Desktop open: NtFC climbs to 7–15 GB, pagefile auto-expands from 4 GB to ~20 GB, C: drive shrinks by 15+ GB
  • System freeze: entire machine becomes unresponsive; only hard reboot recovers it
  • After reboot: NtFC resets to near zero, pagefile shrinks back, C: free space returns

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

# P/Invoke NtQuerySystemInformation(22) to read pool tag table directly
# x64 layout: each entry is 40 bytes, NonPagedUsed at offset 32
# Sampled: NtFC value at T=0, wait 60s, read again → delta/60 = MB/s

Stage 1 (Desktop running, 9 processes, 60-second window):

  • NtFC: 6,990 MB → 7,431 MB = +441 MB in 60s = 7.34 MB/s

Stage 2: Killed all PIDs matching *WindowsApps\Claude_* (9 processes). No claude-code or node.exe processes were touched.

Stage 3 (Desktop killed, 90-second window):

  • NtFC: 7,618 MB → 7,618 MB = +0 MB = 0.00 MB/s

What I ruled out before finding this

  • ASUS software (ArmouryCrate, Aura, etc.) — killed all 17 ASUS processes; NtFC continued at same rate. Eliminated.
  • Riot Vanguard (vgk.sys) — disabled at boot (confirmed Start=4, service Stopped); NtFC continued at ~7.7 MB/s. Eliminated.
  • Intel iaStorVD.sys / Micron mtihint.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.bundle file 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.