Paged pool never drops until reboot, FMfn/MmSt/NtfF

Question

Paged pool never drops until reboot, FMfn/MmSt/NtfF

Nathan Jones 0

Paged pool keeps climbing on this PC until I reboot. Closing programs does nothing.

I don't know what else to try. Main desktop, Windows 11 Pro, 64 GB RAM. Right now it's 25H2, 26200.9168. Task Manager, Memory, Paged pool. After a reboot it's around 300 MB. If I actually use the computer it jumps in steps and just sits there. Last boot I watched it go from ~300 in the morning to over 900 by evening. Closing Discord, RuneLite, Firefox, all of it, the number does not come back down. Only reboot clears it. If I ignore it long enough the machine starts locking up. I'm not talking about Chrome eating RAM. This is the kernel paged pool line.

I have other PCs in the house. Same kind of stuff, Discord, RuneLite, Firefox. They sit at like 450-550 MB paged for days. So I'm pretty sure this isn't "everyone has this and they just don't look."

I already wiped this computer once and put basically just RuneLite and Discord back on. Still did it. I also installed 23H2 and some earlier Win11 builds. Still did it. I didn't go back to Windows 10, I couldn't really find a straightforward way to do that.

I used poolmon / tag dumps. The tags that grow and never give the memory back are FMfn, MmSt, NtfF and Ntff. There's also FMsl and File on the nonpaged side. On one snapshot FMfn had something like 1.42 million allocs and 1.17 million frees, so a huge pile still outstanding. fltmc is Microsoft filters, WdFilter, FileInfo, CldFlt, bfs, bindflt, that kind of thing. I don't need a third party filter in the stack for this to happen.

Weird detail: I had wcifs loaded for a while. Once that was disabled at boot, it stopped climbing overnight when I wasn't even at the PC. During the day when I'm opening files it still stairs up and sticks. I turned Defender real-time off for about a day. The giant spikes (like hundreds of MB in a few minutes, I assume scans) mostly went away. The slow climb was still there.

I ran Driver Verifier with pool tracking only on fltmgr, Ntfs, WdFilter, a couple other filters. Their own outstanding paged bytes barely moved. FMfn still grew a lot. So it doesn't look like WdFilter is "leaking 200 MB of its own pool." It looks like the filename cache / NTFS stream stuff never gets torn down until reboot.

I'm attaching tag history, fltmc, and a full tag dump. I had WPR traces too but they were enormous and I deleted the ETLs. I can capture a short one if someone actually wants it. Please don't ask me for a complete memory dump, this box has 64 GB.

If I ignore it long enough it just keeps growing until the machine is out of memory and starts locking up. It does not level off. Reboot is the only thing that gives the memory back.

I don't need a "reboot more often" answer. I already know that works. I need the pool to actually release without rebooting, or a real bug/fix. If you need a kernel dump instead of complete, tell me how you want it.

0 comments

1 answer

Your answer

Answer 1

Hendrix-V 20,300 Microsoft External Staff Moderator

Hi Nathan Jones,

Thank you for providing such detailed troubleshooting information. Based on everything you've tested, you've already ruled out many of the common causes, including clean Windows installations, different Windows 11 versions, application-specific usage, and basic driver verification checks.

At this stage, the most useful next step would be to collect additional kernel-level diagnostics while the paged pool is actively growing:

Capture a short Windows Performance Recorder (WPR) trace during a period where the paged pool increases significantly.
Configure the system for a Kernel Memory Dump instead of a complete memory dump to reduce storage requirements.
Record several PoolMon snapshots over time to identify which tags continue growing and whether any new tags appear.
Note any file synchronization, cloud storage, virtualization, container, or security-related activity occurring when usage increases.

You mentioned that disabling wcifs reduced overnight growth and that turning off Defender real-time protection reduced large spikes but did not stop the gradual increase. Combined with the observed FMfn growth, this may help narrow the investigation toward file-system activity and filter-manager interactions rather than a traditional application memory leak.

Unfortunately, Windows does not provide a supported mechanism to selectively purge these kernel paged-pool allocations on demand. If the allocations are being legitimately retained by a kernel component, a reboot may be the only way to immediately reclaim that memory until the underlying cause is identified.

Let me know if you need further assistance, feel free to ask me by clicking "Add Comment" or "Add Answer" if you cannot add comment so your response will be visible. Thanks for your effort.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Nathan Jones 0 Reputation points

2026-09-11T13:13:58.0533333+00:00

@Hendrix-V Appreciate the reply. I already did most of that, it was in the text file I attached. Short version:

PoolMon over time is in that dump. Hourly tags while it was climbing. FMfn / MmSt / NtfF / Ntff are the ones that keep going up. Nothing new showed up later in the boot. Allocs stay ahead of frees on FMfn. After I close everything those tags do not come back down. Overnight idle is basically flat once wcifs is off. Next day I use the PC, it stairs up again.

WPR: I already captured Pool traces while this was happening. The ETLs were huge (multiple GB) so I deleted them. What they showed: FMfn allocated from ntoskrnl, stacks going through WdFilter / Ntfs (and wcifs back when that was loaded). I also ran Driver Verifier pool tracking on fltmgr, Ntfs, WdFilter. Those drivers' own outstanding paged bytes barely moved while FMfn grew a lot. So it's not WdFilter sitting on 200MB of its own pool. I can do a short 2-3 minute WPR the next time I see a real jump if you actually have a place to upload an ETL. Feedback Hub only took a .txt.

Kernel dump: I can switch it from complete to kernel. Tell me if you want that and how you want the dump collected. I cant uploading a 64GB complete dump.

When it increases I'm just using the PC. No OneDrive on this machine. WSL is not installed. Hyper-V / vmcompute / wcifs are disabled. I'm not running containers. Defender real-time is on (I already tested it off; spikes got smaller, slow climb stayed). No third party AV. fltmc is Microsoft filters only.

You said Windows can't purge this on demand and reboot may be the only reclaim. That's what I'm already stuck with. Other PCs in the house with the same apps stay at 450-550MB paged for days. This one grows until it locks up. I need this routed to whoever owns Filter Manager / NTFS stream lifetime, not another "try WPR" loop. If a kernel dump or a small ETL is what that team needs, say so and I'll grab it. If the answer is just reboot, say that clearly so I can stop collecting traces.
Hendrix-V 20,300 Reputation points Microsoft External Staff Moderator

2026-09-12T05:24:02.82+00:00

Hi Nathan Jones,

Thank you for the detailed follow-up. Based on everything you've described, it appears you've already completed most of the advanced diagnostics that would typically be requested. At this stage, repeatedly collecting the same PoolMon snapshots or long-duration traces is unlikely to provide substantially different information.

Unfortunately, Windows does not provide a supported method to selectively purge these kernel paged-pool allocations on demand. If the allocations remain referenced by kernel components, rebooting remains the available method to reclaim the memory until the underlying cause can be identified.

I understand your concern, especially since other systems with similar workloads remain stable while this system continues growing until it affects responsiveness. Thank you for taking the time to gather such thorough diagnostics.
Nathan Jones 0 Reputation points

2026-09-13T17:05:44.1966667+00:00

@Hendrix-V is there anyway to send this to another team to be looked at?
Hendrix-V 20,300 Reputation points Microsoft External Staff Moderator

2026-09-16T01:37:27.0833333+00:00

Hi Nathan Jones,

Because diagnostic files may contain sensitive system information, upload them only through the secure workspace provided by Microsoft Support. Microsoft’s guidance distinguishes Feedback Hub (Windows + F) as the place to report and track unexpected Windows behavior, while direct troubleshooting should go through the Get Help app or Microsoft Support.

Please note that this is a user-to-user support forum. Moderators, contributors including external Microsoft employees cannot directly intervene in Microsoft product features or access back-end systems. Our role is limited to providing technical guidance on reported issues, requests, or ideas.