Server 2025 - high CPU and RAM

[jokoenen]

The new Windows update August 29, 2025—KB5064081 (OS Build 26100.5074) Preview
https://support.microsoft.com/en-us/top ... aace788d93
includes according to MS the ReFS fix:
This non-security update includes quality improvements. The following summary outlines key issues addressed by the KB update after you install it. Also, included are available new features. The bold text within the brackets indicates the item or area of the change.

[File system]​​​​​​​ Fixed: An issue in Resilient File System (ReFS) where using backup apps with large files could sometimes exhaust system memory.

[Gostev]

Unfortunately, KB5064081 also does not help in our lab where we have solid reproduction. Perhaps the August patch is still incomplete.

[jokoenen]

Thanks for this valuable info. This prevents us from to much trust in MS.
Jo

[BenM2024]

GUys,

Hate to be the one that says "August update worked for me" but something in updates KB5062553 (Windows server 24h2 2025-07-21), KB5063326(.NET 8 2025-07-28), KB5056579( .NET 3.5-4.8.1 2025-07-28), KB5063878( Server 24h2 2025-08-18), KB5064838(.NET 8 2025-08-25) appears to have done.
I am offsite for that period as it is summer recess but the server keeps trucking. I did disable the backup jobs before I went on 19th July as I didn't want the machine trying them should it update and restart without me being around to keep an eye on things.

Re-enabled the backup jobs last Friday (summer recess means we don't do backups over the last weeks of July/all of August/first week of September) and they mostly ran OK.
Only errors seem to be with pre-existing metafiles from the July backup attempts. Re-synched the repositories and the copy jobs, running with a manual sync for the latest restore point, appear to be behaving as expected.

The server is only using 31.5Gb RAM (out of 96Gb physical RAM) today after the weekend backup jobs and the resync for the repositories/sync of copy jobs.

[Gostev]

The issue is not persistent or immediate, you need to wait for mass backup retention processing to kick in. Although I admit it was not an easy issue to reproduce. At some point our QA got lucky and caught it in a VM, which we then snapshot and can now use to quickly test all the hotfixes and updates by reverting to that snapshot. So far the only thing that really made difference in this lab was the last private fix from Microsoft a few months ago.

[jokoenen]

Hi!
To my experience deleting a huge file will block the computer after a few minutes. Unfortunately I can't test it momentarily since I'm on vacation.
LG
JoKoenen

[Flole]

I'm only doing small backups so the retention apply task completes quite quickly and normally I don't experience this issue, but when I have to delete large files from the backup volume stuff gets really bad. The deletion happens instantly but reclaiming space happens afterwards, and RAM consumption will start to increase after the deletion. I rebooted the machine a few times when it became slow to respond during that process, not sure if that helped. In general the OS seems quite slow/laggy since I upgraded to server 2025.

[BenM2024]

The issue is not persistent or immediate, you need to wait for mass backup retention processing to kick in. Although I admit it was not an easy issue to reproduce...

Indeed - I notice this morning that memory consumption has jumped by 20Gb after a bunch of incrementals and data copies to storage with different retention policies.
The behaviour has improved - usually the server would be so memory locked after one overnight backup run that it would take 5 minutes to log in (becasue of all the swapping required). Now it looks like I can do two or three backups and then reboot.

[karsten123]

2025-09 -> next try

[BenM2024]

OK so I retract my previous optimism

The console was complaining that there was a patch missing- so I disabled all the jobs and ran the update over night.

Came in this mornig to a locked up Windows server. Hard reset got things going again. Everything looked normal so enabled all the backup jobs and updated the host servers as requested by the update process. I ran the copy job to update the VHR with the backup that worked on Monday. - note these jobs read from ReFS volumes but do not write to them (at least I don't think they do). I am guessing that as they are synthetic fulls there will be quite a bit of reading of big files going on in the ReFS volumes,

Copies ran OK, memory use looked reasonable(ish) and the copy jobs worked.

Now the server is unresponsive, just like before. Guess I am back to the daily reboot and pray that it survives long enough to run the backups. The server does seem to take longer to break but that is a gut feel rather than empirical measurement!

Roll on Patch Tuesday!

[Didi7]

Thank god there is VSA *yippieh*

[ChristophINV]

Joined the club for a couple of weeks now. Installed a fresh 2025-Server with a 60 TB ReFS-Repo (as a planned replacement for an EOL physical server) and on its initial Backup it took more than 20 hours for the issue to appear (VM ran into "Freeze", nothing but answering Pings). After that, it basically kicked in with every Retry/Reset immediately and even with another Job within 30 minutes. After wasting almost an entire weekend I found this thread (thankfully!).

In the Windows-App-Eventlog I found this just a couple of minutes before the machine got unresponsive the first time:

Fault bucket 2136014573521082570, type 5
Event Name: RADAR_PRE_LEAK_64
Response: Not available
Cab Id: 0

Source: Windows Error Reporting
Even ID: 1001

And then filtering for that, I saw that (Event, not freezes!) happening two weeks earlier (the server was basically just sitting there, installed Veeam one week before), these errors seem to have happened erratically on random processes, that were active:

MicrosoftEdgeUpdate.exe
WindowsWcpOtherFailure3
TiWorker.exe
Veeam.Backup.RestAPIService.exe
Veeam.Backup.Service.exe
Veeam.Backup.CloudService.exe
VeeamAgent.exe
msedge.exe
SenseNdr.exe
svchost.exe_defragsvc

And as it is "Informational", who looks really into those messages? And yes, why the "defrag" was a thing on my Backup-Server (sorted)...that event happened three minutes before the Server went unresponsive for the first time.

Since almost three weeks I'm begging Microsoft-Partner-Support, but they refuse to even recognize what I'm talking about. It is slightly frustrating, as we have basically set up everything already.

[m.novelli]

That's a ridicolous to still have to install Windows Server 2022 after almost one year of Windows Server 2025

Marco

[Gostev]

Thank god there is VSA *yippieh*

As you said elsewhere, this whole issue makes the decision to go with Veeam Software Appliance an easy one.

[mkretzer]

... or just use plain old Linux repos with XFS. Everything is better than ReFS on WIndows.

[BenM2024]

tl;dr - September patches have done something; not sure if the machine will survive the night but hope is high!

Yesterday I applied 2025-09 server update (2025-09 Cumulative Update for Microsoft server operating system version 24H2 for x64-based Systems (KB5065426)) and left the machine to its own devices with the backup jobs (yeh I forgot to disable them before doing the windows update), which turned out to be 'interesting'.

Having sorted out the mess with a couple of hard reboots (one becasue of the known ReFS issue causig the machine to lock up when it got owards the end of the backup jobs, the other becasue the patch installation got as far as rebooting the machine then just hung with the word "Restarting..." on the console) I kept an eye on memory use.

What happened was that the indicated memory use climbed steadily, then dropped back a bit and then instantly climbed a bit, then gradually increased until it was higher than the point at which it dopped back, rinse and repeat to a max of about 80Gb. It stayed up high for quite a while then dropped suddenly to about 20Gb and there remained for a while.

Whilst typing this memory use appears to be slowly rising again - about 100Mb increase every 8-16 seconds or so. It reached about 28.4Gb and just dropped back to 24.3Gb again - no, wait, its dropped again to 16.3Gb and is slowly climbing again; this seems to be cyclical - definitely repeated the 16Gb to 28.4Gbish slow climb then drop back to 24Gb then 16Gb a couple of times.

Pure speculation - something has changed with yesterday's patch that makes the system much more likely to free memory for whatever reason.

With that optimism in my heart I am going to let the backups run tonight and hope to be able to say "it's all still working" in the morning

[Flole]

I saw this rising and then dropping last month already, let's see what the morning brings for you though

[johan.h]

I've been told that the next possible time we expect a public update that may not require additional enablement around ReFS garbage collection (related to the retention processing performance impact) from Microsoft is December this year.

[BenM2024]

Well guys it's party time in my Veeam server!

Full set of incrementals completed last night, a couple of copies to the VHR, a SureBackup test and RAM doing the cyclical thing this morning between 29Gb and 24Gb... the minimum RAM in use has gone up by 8Gb so lets see what Monday brings there.

All the full backups get done tonight/over the weekend so I am looking forward to a responsive server on Monday.

FWIW the only ReFS reg setting I have enabled is

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
Value Name: RefsEnableLargeWorkingSetTrim
Set RefsEnableLargeWorkingSetTrim = 1
Value Type: REG_DWORD

documented here

Which, if the weekend backup is successful and the baseline RAM hasn't gone up by too much, I will disable on Monday and see how that changes anything.