Windows Version
Windows 11 Enterprise 10.0.26200.8973
WSL Version
2.7.11.0
Are you using WSL 1 or WSL 2?
Kernel Version
6.18.33.2
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
- Reboot Windows and record PoolMon/pool counters.
- Start WSL 2.
- Perform high-volume filesystem enumeration across the Windows/WSL
boundary, such as recursively examining many files under /mnt/d.
- Observe WCsc/WCri/FMfn and total paged pool grow.
- Stop the operation and run
wsl --shutdown.
- Observe that the leaked pool remains allocated.
A diagnostic operation writing Windows output to \\wsl.localhost\Ubuntu\... also reproduced rapid WCsc allocation growth during an instrumented WPR trace.
Expected Behavior
Filesystem contexts and Filter Manager name-cache entries are freed after the requests and WSL instance finish.
Actual Behavior
The allocations remain outstanding indefinitely, accumulating until Windows is rebooted.
Diagnostic Logs
I have a very large wcifs-active-leak-2026-08-09.etl file I can share privately for diagnostics if necessary.
Summary
High-volume filesystem access across the WSL/Windows boundary causes
unbounded Windows paged and nonpaged kernel-pool growth.
The affected paths include Linux access to Windows drives through /mnt/d
and Windows access to Linux through \\wsl.localhost.
The leaked memory is not released by closing the originating application or
by wsl --shutdown. A complete Windows reboot is required.
Impact
Paged pool reached approximately 28.3 GB and nonpaged pool approximately
18.4 GB on a 48 GB system, resulting in nearly complete memory exhaustion.
After reboot, pool usage returned to normal. Repeating cross-filesystem file
activity caused it to grow again by several GB.
PoolMon attribution
Dominant tags included:
- FMfn: Filter Manager name cache
- WCsc
- WCri
- WCfc
- WCss
- WCse
- File
- IoNm
- NtfC
The WC* tags were verified as strings in wcifs.sys.
During one active trace, WCsc outstanding allocations increased from
approximately 448,000 to 930,000.
WPA/WPR stack attribution
A WPR Pool.Verbose trace shows outstanding WCsc allocations with stacks
containing:
dllhost.exe
-> ntoskrnl.exe
-> FLTMGR.SYS
-> wcifs.sys
The relevant dllhost.exe instance was:
C:\Windows\System32\DllHost.exe
/Processid:{DFB65C4C-B34F-435D-AFE9-A86218684AA8}
More than 90% of outstanding allocations for several dominant tags,
including FMfn, WCsc, WCri, and FMfc, had vp9fs.dll in their stack.
Additional information
- No Windows containers or Rancher Desktop were involved.
- Closing the originating applications does not release the memory.
wsl --shutdown does not release the memory.- WSL 2.7.11 was the latest version offered by
winget at the time.
- An approximately 349 MB WPR Pool.Verbose ETL trace is available privately.
Windows Version
Windows 11 Enterprise 10.0.26200.8973
WSL Version
2.7.11.0
Are you using WSL 1 or WSL 2?
Kernel Version
6.18.33.2
Distro Version
Ubuntu 22.04
Other Software
No response
Repro Steps
boundary, such as recursively examining many files under
/mnt/d.wsl --shutdown.A diagnostic operation writing Windows output to
\\wsl.localhost\Ubuntu\...also reproduced rapid WCsc allocation growth during an instrumented WPR trace.Expected Behavior
Filesystem contexts and Filter Manager name-cache entries are freed after the requests and WSL instance finish.
Actual Behavior
The allocations remain outstanding indefinitely, accumulating until Windows is rebooted.
Diagnostic Logs
I have a very large
wcifs-active-leak-2026-08-09.etlfile I can share privately for diagnostics if necessary.Summary
High-volume filesystem access across the WSL/Windows boundary causes
unbounded Windows paged and nonpaged kernel-pool growth.
The affected paths include Linux access to Windows drives through
/mnt/dand Windows access to Linux through
\\wsl.localhost.The leaked memory is not released by closing the originating application or
by
wsl --shutdown. A complete Windows reboot is required.Impact
Paged pool reached approximately 28.3 GB and nonpaged pool approximately
18.4 GB on a 48 GB system, resulting in nearly complete memory exhaustion.
After reboot, pool usage returned to normal. Repeating cross-filesystem file
activity caused it to grow again by several GB.
PoolMon attribution
Dominant tags included:
The WC* tags were verified as strings in
wcifs.sys.During one active trace, WCsc outstanding allocations increased from
approximately 448,000 to 930,000.
WPA/WPR stack attribution
A WPR Pool.Verbose trace shows outstanding WCsc allocations with stacks
containing:
dllhost.exe
-> ntoskrnl.exe
-> FLTMGR.SYS
-> wcifs.sys
The relevant dllhost.exe instance was:
C:\Windows\System32\DllHost.exe
/Processid:{DFB65C4C-B34F-435D-AFE9-A86218684AA8}
More than 90% of outstanding allocations for several dominant tags,
including FMfn, WCsc, WCri, and FMfc, had
vp9fs.dllin their stack.Additional information
wsl --shutdowndoes not release the memory.wingetat the time.