NtFC Non-Paged Pool Leak — Evidence Report

Machine: Windows 11 Pro 25H2, build 26200.9457
Captured: 2026-09-18 15:39 (CST)
Status: 21.35 GB pinned in non-paged pool; currently static (not advancing)

Follow-up to #40804 (ntfs.sys NtFC non-paged pool leak: ~21 GB/hr with WSL2 on Windows 11 26200.x), which was closed as NOT_PLANNED on
2026-06-17 without a stated fix plan.

This report confirms the defect is still present on the latest servicing
build (26200.9457 + KB5129195 installed 2026-09-17), adds two pieces of
evidence not present in the original thread, and restates the ask.

Also relevant to #41296 (wcifs.sys pool leak) and
microsoft/Windows-Containers#646.

0. Environment (issue template fields)

1. Summary

NtFC (owned by ntfs.sys) holds 21,353.2 MB in non-paged pool on a
32 GB machine, with no user-space process accounting for it. All 384
processes' working sets sum to 7,301 MB. The kernel pool is ~3x larger than
all user-space memory combined.

Available physical memory: ~500 MB.

Stability evidence: NtFC read 21,353.2 MB byte-identical across two
independent captures ~1 hour apart (14:37 and 15:39 CST), while aggregate
non-paged pool and available memory fluctuated by tens of MB. This
distinguishes the condition from a normal cache: the 21 GB is pinned, not
merely resident, and is not being recycled.

This matches the pattern reported in #40804 and
microsoft/Windows-Containers#646 (wcifs.sys retaining
FLT_STREAM_CONTEXT / FLT_FILE_CONTEXT references above NTFS, preventing
ntfs.sys from freeing FCBs tagged NtFC).

2. Memory state

The kernel holds more memory than every user-space process combined.

3. Pool tag attribution

Query method: NtQuerySystemInformation(SystemPoolTagInformation) = class 22,
structure stride 40 bytes (x64), NonPagedUsed at +32.

Total tagged non-paged pool: 21,982 MB

Top 15 non-paged tags

NtFC = 97.1 % of all tagged non-paged pool, = 65.5 % of installed RAM.

Tag owner confirmed by binary scan: the 4-byte sequence 4E 74 46 43 is
present in C:\Windows\System32\drivers\ntfs.sys. NtFC is listed in
Microsoft's pool tag reference as "NTFS File Context" (also cited as
"ntfs.sys Fcb" on some builds).

Paged pool (for contrast — this is not the leak)

Paged pool is unremarkable (1,119 MB total). For contrast, the machine in
#41296 (comment by spencer-shadley) showed 30 GB of paged
pool dominated by Toke / FMfn — a different manifestation. Here the
anomaly is exclusively non-paged and exclusively NtFC.

4. Growth rate

60-second observation window:

NP pool T0      : 23518 MB
NP pool T1      : 23518 MB
Delta over 60s  : 0.066 MB  =>  4.0 MB/hr  =>  95.6 MB/day
Interpretation  : STATIC - leak not currently advancing

Earlier 15-second and 120-second windows showed +0.03 MB and +0.34 MB
respectively. The 21 GB is pinned/retained, not actively growing right now.

NtFC itself did not move at all between captures: 21,353.2 MB at both
14:37 and 15:39 CST. Only aggregate pool moved by rounding-level amounts.
This is the signature of retention, not of an active leak.

Growth is expected to resume at the reported 21–23 GB/hr once the triggering
workload (WSL2 / VHDX I/O) runs again — this machine had WSL stopped during
the entire observation window, which is why the rate reads ~0.

5. Environment — why this machine matches the trigger profile

Filter drivers

wcifs.sys sits at altitude 189900, above NTFS. Per the analysis in
microsoft/Windows-Containers#646, a minifilter holding a stream context on a
file prevents NTFS from freeing that FCB — the FCB is still referenced.

WSL2 / Docker

WSL version     : 2.7.10.0
WSL kernel      : 6.18.33.2-2
WSLg            : 1.0.73.2
Distros         : docker-desktop (v2), Ubuntu-24.04 (v2)
wslservice      : Running, StartType = Automatic
Docker Desktop  : HKCU\...\Run autostart enabled

Virtual disk placement (the reported trigger)

All VHDX files are on NTFS volumes. Note the Docker path is a
junction — C:\Users\23546\AppData\Local\Docker\wsl is a reparse point
to E:\UserData\Docker\wsl-data, so the payload physically lives on E:.

Volume layout: C: 231.8 GB NTFS, D: 931.5 GB NTFS, E: 931.5 GB NTFS.

Journalled junction resolution:

> Get-Item 'C:\Users\23546\AppData\Local\Docker\wsl' | Select LinkType, Target
LinkType : Junction
Target   : E:\UserData\Docker\wsl-data

WSL registry BasePath values confirm: docker-desktop resolves to
\\?\C:\Users\23546\AppData\Local\Docker\wsl\main (the junction path),
Ubuntu-24.04 to E:\UserData\WSL\Ubuntu-24.04.

Upstream report #40804 identifies Hyper-V VHDX block I/O against NTFS as
the dominant source, not the 9P/DrvFS bridge.

Second VHDX consumer present: Claude Cowork VM

This machine also runs a second, independent Hyper-V-backed VM
subsystem that holds VHDX files open:

Service  : CoworkVMService  ("Claude")
Status   : Running
StartType: Automatic
Bundle   : E:\UserData\Claude\vm_bundles\claudevm.bundle\
           rootfs.vhdx 7.7 GB, sessiondata.vhdx 0.7 GB, smol-bin.vhdx 36 MB

This is directly relevant: anthropics/claude-code#94198 reports
"CoworkVMService non-paged pool leak (NtFC/ntfs.sys) — Restart clears it,
Shutdown does not", and #91265 reports the same service causing
persistent kernel pool growth on Windows.

At capture time no VM was actively running (vmmem/vmwp absent,
Msvm_ComputerSystem VM count = 0; vmcompute running as a stub), so this
service is a latent second trigger path, not the active cause of the
current retained pool. It is listed here because it must be accounted for
when attributing the leak and when testing any workaround.

Users diagnosing this on Claude Desktop machines should therefore isolate
which of the two VM subsystems (WSL2/Docker vs Cowork) drives a given
growth episode — the pool tag is the same for both.

Updates installed (bug still present)

Build is 26200.9457 — the most recent CU does not fix this.

Fast Startup is ON

HiberbootEnabled = 1

This matters: a shutdown + power-on restores the hibernated kernel
session and the 21 GB comes back. Only a true restart clears it.
Users should be told this explicitly — it is a common failure mode when
following "reboot to fix it" advice.

6. Reproduction / verification steps

Any reader can reproduce the measurement:

# Pool tag table (no admin required)
Add-Type -TypeDefinition @"
using System; using System.Runtime.InteropServices;
public class P { [DllImport("ntdll.dll")] public static extern int
NtQuerySystemInformation(int c, IntPtr b, int l, out int r); }
"@
$buf = [Runtime.InteropServices.Marshal]::AllocHGlobal(1MB)
$r = 0
[P]::NtQuerySystemInformation(22, $buf, 1MB, [ref]$r)
$n = [Runtime.InteropServices.Marshal]::ReadInt32($buf, 0)
for ($i=0; $i -lt $n; $i++) {
  $o = 8 + $i*40
  $t = -join (0..3 | ForEach-Object { [char][Runtime.InteropServices.Marshal]::ReadByte($buf,$o+$_) })
  $np = [Runtime.InteropServices.Marshal]::ReadInt64($buf, $o+32)
  if ($np -gt 100MB) { "{0,-6} {1,10:N1} MB" -f $t, ($np/1MB) }
}

Expected (current machine): NtFC at ~21,353 MB.

Corroborating counters:

(Get-CimInstance Win32_PerfRawData_PerfOS_Memory).PoolNonpagedBytes / 1MB
# -> 23322

7. Impact

• On a 32 GB machine, 65 % of RAM is permanently unavailable until restart.
• Available physical memory sits at 513 MB; any memory spike
  (a build, a large browser session, a container start) can trigger
  OOM or a full system freeze.
• wsl --shutdown does not release it (measured upstream: ~6.5 GB residual).
• A shutdown + power-on does not clear it either on this machine:
  HiberbootEnabled = 1 (Fast Startup) restores the hibernated kernel
  session, bringing the 21 GB straight back. Only a true restart clears it —
  and it returns as soon as WSL2 is used again.

8. Workarounds available to the user (none fix the root cause)

Disabling wcifs (Start=4) is theoretically the nearest thing to a
root-cause avoidance, but it would break Windows Containers, Windows
Sandbox, MSIX mount paths, and likely Docker Desktop. Not recommended
and not tested here.

9. Upstream references

The wcifs-above-NTFS ownership theory is from a contributor analysis in
#41296: five wcifs context tags (WCsc, WCfc, WCse, WCss, WCri)
settle at identical live counts with 0 frees, while WCfn on the same
per-file path frees 100 % — implying contexts are pinned, not leaked in
the NTFS free path.

10. Ask

1. Is this a known regression in the 26200.x servicing branch?
2. Can the NTFS FCB release path be fixed to free NtFC on final
   Hyper-V handle close, or can wcifs be fixed to release its
   stream/file contexts?
3. If a fix is planned, what is the target servicing build?
4. In the interim, is a supported way to force-release pinned NtFC
   structures without a full restart? (wsl --shutdown is insufficient.)

Evidence can be extended on request: PoolMon / pool-tag time series,
fltmc filters + fltmc instances output (requires elevation), WPR ETL
storage trace, or a live allocation-stack capture on a second debug host.

Generated from automated instrumentation on the affected machine.
Raw snapshot: evidence-snapshot.txt.