Windows 11 25H2 kernel pool leak: FMfn and File allocations retained after cold path operations

Question

I am investigating a repeatable kernel pool retention issue on Windows 11 Pro 25H2, build 26200.8973, with 32 GB RAM.

The machine continuously accumulates paged and nonpaged kernel pool. Growth is dominated by Filter Manager and file-object tags including FMfn, FMsc, FMsl, File, IoFE, IoNm, NtfF and NtFC. A reboot clears the allocations, but the same curve restarts.

Before mitigation, combined pool reached 24.4 GB after 47.41 hours: 10,786 MB nonpaged and 13,626 MB paged. Targeted workload reductions lowered the rate, but did not remove the mechanism. A later 71.85-hour boot still ended at 5,366 MB combined pool. After KB5101684, a fresh 5.67-hour active window rose from 1,094 to 1,630 MB nonpaged and 608 to 1,660 MB paged, about 280 MB/hour combined.

Controlled tests show the charge is tied to cold file-name operations:

• 3,000 first-time opens cost about 1 KB of pool per path.
• 3,000 new file creates cost between 2.1 KB and 7.9 KB per path across different boots.
• Reopening the same warm paths adds no measurable charge.
• The added pool did not release during the observation windows.

Local isolation already performed:

• Microsoft Defender real-time protection and behaviour monitoring were confirmed off during one controlled probe. The per-create charge remained unchanged, then protection was restored.
• CldFlt was detached for a controlled A/B. The FMfn slope and identical workload cost were unchanged, then the filter was reattached.
• Windows Search was stopped, excluded for all user profiles and reset. Growth continued with the indexer idle and recording no I/O.
• The loaded filesystem filter set is Microsoft-only. No third-party minifilter is present.
• Process handle counts and visible working sets do not account for the retained kernel memory.
• Firmware and Windows cumulative updates did not remove the issue. There are no WHEA, storage, NTFS or bugcheck errors associated with the pool growth.

This points to the Microsoft Filter Manager name-cache path or NTFS name handling below active scanning. Has Microsoft identified a known defect for this FMfn plus File retention pattern on Windows 11 25H2? Is there a supported trace that can attribute the retained allocations without collecting memory contents or full file paths, and is there a supported mitigation other than rebooting?

For privacy, I have intentionally not attached raw ETL traces, memory dumps, file-path logs or local files. I can provide redacted counter and pool-tag tables if needed.

Answer 1

Welcome to Microsoft Q&A!

Thank you for providing such detailed troubleshooting data and for clearly documenting the isolation steps you have already performed.

Based on the information provided, I am not aware of any publicly documented Microsoft issue that specifically describes this FMfn/FMsc/FMsl plus File/NTFS kernel pool retention pattern on Windows 11 25H2.

The pool tags you identified are associated with the Windows file system stack, particularly Filter Manager (fltmgr.sys) name-cache activity and NTFS/file-object related structures. Your testing has already ruled out several common contributors:

• Microsoft Defender real-time protection and behavioral monitoring.
• Cloud Files (CldFlt).
• Windows Search indexing activity.
• Third-party minifilter drivers.
• User-mode handle or working set growth.

Given these results, the behavior appears more closely related to Filter Manager and/or NTFS processing than to a third-party filter driver.

That said, growth in FMfn allocations alone does not necessarily indicate a memory leak. Filter Manager maintains file-name cache structures that can expand during cold-path file operations. In some scenarios, these allocations may remain resident for extended periods and are not immediately reclaimed unless memory pressure occurs.

For further investigation, I would recommend collecting supported diagnostic data such as:

1. PoolMon output to track pool-tag growth over time. PoolMon is the supported tool for monitoring paged and nonpaged pool allocations and identifying allocation patterns by pool tag. Please states that PoolMon is commonly used to investigate driver memory leaks and pool usage.
2. WPR/WPA (ETW) traces with File I/O, Pool, and Filter Manager providers enabled to correlate file operations with allocation growth.
3. Filter topology information (fltmc filters and fltmc instances) to confirm which Microsoft filters are participating in the create/open path.

Based on your controlled testing:

• First-time opens and file create increase pool usage.
• Reopening previously accessed paths does not.
• Allocations remain resident throughout the observation period.

This pattern is consistent with either long-lived name-cache retention or a potential cache reclamation regression. However, allocation ownership cannot be conclusively determined from pool-tag statistics alone.

Currently, there is no documented mitigation for this behavior other than identifying the component responsible for the allocations and, if necessary, please consider engaging Microsoft Support. Since you have a reproducible workload and have already eliminated several common causes, a support case accompanied by PoolMon data and ETW traces would be the recommended next step for deeper analysis by the Windows File Systems or Filter Manager engineering teams.
Reference: PoolMon - Overview - Windows drivers | Microsoft Learn

If you find this answer helpful, please click Accept Answer.

Thank you for using Microsoft Q&A!