High non-paged pool memory usage on S2D failover clusters - refs.sys?

Question

High non-paged pool memory usage on S2D failover clusters - refs.sys?

Peter Camps 10

After several updates in August 2026 (Windows updates (KB5101372), secure boot certificates and HPE SPP P95170_001_gen10spp-2026.05.00.00-SPP2026050000.2026_0527.9) we are experiencing what looks like a memory leak on all Windows 2025 Core Hyper-V servers in S2D failover clusters. The non-paged pool is steadily increasing and eventually leads to a non-responsive host. After a reboot the non-paged pool starts at about 5 GB and eventually grows to several hundreds GB.

Poolmon shows after reboot about 1 week ago:

User's image

Refs.sys shows high usage. The version of refs.sys was 10.0.26100.33158. After discovering the problems we started installing KB5122871 and got refs.sys version 10.0.26100.33438. But the problem is still unresolved. At this moment we need to reboot the Hyper-V servers every few weeks to bring the non-paged pool usage back down.

We are using HPE Proliant DL380 Gen10 Plus servers with NVMe drives, Intel(R) Ethernet Network Adapter E810-XXVDA4 NIC's.

All storage is configured as 3-way mirror with CSVFS_ReFS

Windows Server Core 2025

But even in my small (virtual) test cluster i can see that the non-paged pool is steadily increasing. This is a nested Hyper-V cluster with no third party drivers.

Anybody experiencing the same issue? Or have a resolution for this problem?

Peter Camps

0 comments

1 answer

Your answer

Answer 1

Hi Peter Camps,

Your poolmon.exe capture shows that the MSPi pool taghas nearly 12 million unfreed allocations consuming roughly 49 GB of Non-Paged Pool (Nonp) RAM after one week. You reproduced this exact Non-Paged Pool growth in a nested virtual Hyper-V cluster with no third-party drivers, the HPE Gen10 SPP firmware and Intel E810-XXVDA4 drivers are ruled out as root causes. While KB5101372 (the Servicing Stack Update bundled with the July 2026 Cumulative Update KB5099536, build 10.0.26100.33158) and the September 8, 2026 Cumulative Update KB5122871 (build 10.0.26100.33438) updated refs.sys, neither resolved this leak, and the September 14, 2026 Out-of-Band update (KB5129235, build 10.0.26100.33451) only addresses Remote Desktop and USB audio issues. This seems an unresolved Microsoft bug in refs.sys, there is no permanent fix yet, and you will need to wait for an official Microsoft Cumulative Update that patches the MSPi leak.

While waiting for an official Microsoft fix, you can configure Microsoft's documented ReFS metadata trimming parameters under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem on every cluster node by creating the REG_DWORD values RefsEnableLargeWorkingSetTrim set to 1, RefsEnableInlineTrim set to 1, and RefsNumberOfChunksToTrim set to 16 or 32, followed by a rolling node reboot. These parameters force refs.sys to unmap inactive metadata streams inline and at every checkpoint rather than relying on lazy garbage collection; however, because they primarily trim the ReFS metadata working set rather than freeing leaked MSPi Non-Paged Pool pages, they may only modestly reduce memory pressure. To preserve Non-Paged Pool headroom and prevent Srv Event ID 2019 pool exhaustion hangs, check (Get-Cluster).BlockCacheSize in PowerShell to ensure the CSV Block Cache (which also allocates from Non-Paged Pool RAM) is kept conservative, continue scheduling rolling node reboots via Suspend-ClusterNode -Drain, and log a support case with Microsoft Support with your poolmon.exe output and a non-disruptive kernel live dump (Get-StorageDiagnosticInfo or livekd) to escalate the refs.sys defect.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN

Peter Camps 10 Reputation points

2026-10-02T13:18:55.23+00:00

Hi VPHAN,

Thanks for your reply, I dropped this case at our distributor and hope to get an (Microsoft) answer for this issue. Our current Premier Support contract cannot be used because of an ongoing usage conflict.

I also saw the 3 registry settings for ReFS metadata trimming parameters, but was unsure if this would be a "solution" for our CSVFS_ReFS volumes. I have seen these settings a lot for ongoing ReFS issues on Veeam repository servers, was not sure if this could be implemeted on our Hyper-V hosts without creating other issues.

I am going to test this first in my virtual cluster, see what is happening. Of course I won't be able to simulate the load like we have on the live clusters but maybe it will give me new insights.

(Get-Cluster).BlockCacheSize = 1024 on all nodes

Thanks for your reply

Peter