[BUG] [BUG] CoworkVMService non-paged pool leak (NtFC/ntfs.sys) — Restart clears it, Shutdown does not
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?
Related to #55361 (auto-closed as duplicate of #29045) and #57247. Filing fresh since #55361 is locked and I have an additional diagnostic finding not previously documented.
Environment: Windows 11 Home, Version 25H2 (OS Build 26200.9445), 16GB RAM.
I experienced this exact issue. System reached 99% memory usage / Nonpaged Pool at ~11.6GB, confirmed via poolmon that NtFC (ntfs.sys - Create.c) was responsible for ~10.9GB of that, with fltmc filters showing bindflt and wcifs active.
Key finding: Shutting down and powering back on did NOT clear the leak — memory stayed at 99% immediately after boot. However, using Restart (not Shutdown) fully cleared it back to normal levels. This is likely because Windows Fast Startup hibernates the kernel session on Shutdown instead of doing a true cold boot, so the leaked kernel pool state survives a normal shutdown/power-on cycle, but a genuine Restart forces a full kernel reinitialization.
This might be a useful distinction for others hitting this bug and assuming a full power cycle should fix it — a Restart is required, or Fast Startup needs to be disabled for a Shutdown to actually clear it too.
Confirmed CoworkVMService (from Claude_1.52386.3.0_x64 package, binary at cowork-svc.exe) is registered as AUTO_START, so it relaunches on every boot regardless of whether the Claude Desktop app itself is manually opened.
Happy to provide additional poolmon captures or logs if helpful.
What Should Happen?
The Windows kernel's non-paged pool should not grow unbounded from CoworkVMService's filesystem operations. Memory used by NtFC (ntfs.sys) allocations related to Cowork's file access should be properly released when Cowork sessions end, and should not persist even after a normal Shutdown/power-on cycle — only after a full Restart currently works.
Error Messages/Logs
No explicit error dialog was shown. Diagnostic evidence is the poolmon output showing NtFC tag with a large gap between Allocs and Frees (tens of millions of outstanding allocations), consistent with prior reports in #55361 and #57247.Steps to Reproduce
- Install Claude Desktop with Cowork on Windows 11 (16GB RAM in my case).
- Use Cowork normally for an extended session involving file operations.
- Open Task Manager and observe Memory usage climbing toward 99%.
- Open an elevated terminal, navigate to the WDK tools folder, and run:
poolmon /g "C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\triage\pooltag.txt"
- Press P once (nonpaged pool only), then B (sort by bytes).
- Observe the NtFC tag (mapped to ntfs.sys - Create.c) dominating nonpaged pool usage (~10.9GB in my case, out of ~11.6GB total nonpaged pool).
- Run "fltmc filters" and confirm bindflt and wcifs are active.
- Shut down the PC completely (Start > Power > Shut down), wait, then power back on — memory usage remains at 99% even before opening any app.
- Instead, use Restart (Start > Power > Restart) — memory usage returns to normal immediately after boot, before opening any app.
- Run "sc.exe query CoworkVMService" to confirm it is registered as AUTO_START and relaunches every boot regardless of whether Claude Desktop is manually opened.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
No response
Claude Code Version
N/A — using Claude Desktop app, not Claude Code CLI. App version: Claude 1.52386.6 (612f3f), built 2026-09-13T00:45:40.000Z
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
Related to #55361 (auto-closed as duplicate of #29045) and #57247. Filing fresh since #55361 is locked and I have an additional diagnostic finding not previously documented.
Environment: Windows 11 Home, Version 25H2 (OS Build 26200.9445), 16GB RAM. Claude Desktop version 1.52386.6 (612f3f).
Key finding: Shutting down and powering back on did NOT clear the leak — memory stayed at 99% immediately after boot. However, using Restart (not Shutdown) fully cleared it back to normal levels. This is likely because Windows Fast Startup hibernates the kernel session on Shutdown instead of doing a true cold boot, so the leaked kernel pool state survives a normal shutdown/power-on cycle, but a genuine Restart forces a full kernel reinitialization.
This might be a useful distinction for others hitting this bug and assuming a full power cycle should fix it — a Restart is required, or Fast Startup needs to be disabled for a Shutdown to actually clear it too.
Confirmed CoworkVMService (from the Claude_x64 WindowsApps package, binary at cowork-svc.exe) is registered as AUTO_START, so it relaunches on every boot regardless of whether the Claude Desktop app itself is manually opened.
Happy to provide additional poolmon captures or logs if helpful.