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.

[BenM2024]

Here we are, Monday... and all is well in Veeam B&R Server land with Windows Server 2025 and ReFS - at least as far as I can tell.
Full backups completed over the weekend, copies to VHR and some SureBackup jobs, all completed successfully.

Server Ram starts at about 25Gb used and goes up as it was doing on Friday - so no significant baseline RAM increase but there is an increase though 1Gb per night means it will be 2 months before the baseline meets physical RAM; pretty sure the server wil be rebooted before then!

I am fairly sure that whatever was broken has been fixed, for special values of fixed, but I will be keeping a close eye on things and, of course, will post back here if things change.

[Heimer-BEAS]

I can not confirm the positive message from the previous post.
We have a Veeam Backup Server that is a physical box with 3 64TB REFS SAN (HPE 3PAR) volumes attached over Fiber Channel Multipath.
Issues started last month, Server would just freeze up over night and only reply to pings, after hard resets i could watch the CPU utilization going to 100% soon after the Veeam Services started and then RAM would max out (at the time it was 64GB). Luckily i have a bunch of unused servers whose workloads got moved into VM's so i could just plug the server with 512GB of RAM.

Then i could see the RAM usage go up to 120GB and after an hour or so it settled at 90GB ish.
After this the Veeam Server was running without reboot for the remainder of August, and at some point in time the RAM usage went back to normal levels (about 30GB).

Now last Friday i noticed "stuck" backup jobs from Thursday night again; and, thinking that "the promised Update from Microsoft has surely arrived by now" i foolishly rebooted my Veeam Server.

The result was that the box refused to boot for over 1h, just being stuck in the "spinning circle" screen. Only after i pulled out the FC-SFP connectors would the server actually boot.
But wait, there's more!
It would boot into a black screen with a mouse cursor (no desktop, start menu or task manager) and stay there for the 20 or so minutes that i had the patience to wait.

After the first time i ran into the REFS bug i set up local backups of the Veeam server on 2 external SSD's so i just restored backups day by day until i got back to a "working" Windows Server.
That restore from Monday, 08.09.25 did boot into a "normal looking" Desktop but neither the start-menu nor any of the "modern UI" elements of Server 2025 would work, i could only access the "old" control panel.
So finally i restored to the oldest backup i had and then restored the Veeam Server Config. I turned off Windows Updates for the moment.

So now that i have a mostly working Veeam Server again, i dare to plug the FC-SFP's back in. Windows will set the volumes to "offline" by default, upon clicking "online" on the first 64TB volume i could see immediately 100% read activity on the volume in task manager by the process "Veeam.Backup.Manager.exe". This would go on indefinitely.
At the same time none of my scheduled or manually started backup jobs would run with the error:

I had to manually kill the DatabaseResynchronizer task every time a new backup job would start.
Now i have taken the REFS volumes offline since coincidentally i have deleted the CatalystStores from our "old" backup software and I now have enough space to back up our fileservers into the StoreOnce appliances. Previously they did not have enough capacity, hence why i set up the REFS volumes on our old 3PAR SAN.

The takeaway from this is that Microsoft is a small indie startup and cannot be expected to do QA testing before rolling out software.
We as users shouldn't be so needy and just accept that we have to be the QA testers instead.

The icing on the cake is that Azure Norway East had a partial outage for almost the entire day on the 12th and the result of this is that we have to delete and recreate about 9 VM's from our SAP DEV and QA environments (thank god PROD wasn't affected).

[Ken.Ellis]

Here we are, Monday... and all is well in Veeam B&R Server land with Windows Server 2025 and ReFS - at least as far as I can tell.
Full backups completed over the weekend, copies to VHR and some SureBackup jobs, all completed successfully.
...
I am fairly sure that whatever was broken has been fixed, for special values of fixed, but I will be keeping a close eye on things and, of course, will post back here if things change.

Are you doing synthetic full backups as part of this, and has it used ReFS Fast Clone to perform synthetic full / merging yet? Everything looked good and fine to me for a week or two at the beginning as well when it was just doing regular fulls and incrementals, but as soon as it starts using ReFS Fast Clone in any serious way is when everything fell apart, at least for us. Good luck!

[ChristophINV]

I'm somewhat reluctant to give it another try yet. May I ask around, if any of you affected are as well seeing these kind of random 1001-Events in the Windows Applications-Eventlog, regarding these supposedly Memory-Leaks?

I've zero entries since the original issue on August 17th (Server just sitting there online, doing nothing else), so I just logged on to apply "9. September 2025 – KB5065426 (BS-Build 26100.65840)" Patch, and within three minutes, I got another one of these:


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

Problem signature:
P1: Veeam.Backup.Service.exe
P2: 12.3.2.3617
P3: 10.0.26100.2.0.0
P4:
P5:
P6:
P7:
P8:
P9:
P10:

Attached files:
\\?\C:\Users\Administrator\AppData\Local\Temp\RDRAFE6.tmp\empty.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.f85a7ccf-eccf-4c1c-ad54-60ddf2bcdb14.tmp.WERInternalMetadata.xml
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.5525252a-ef16-4f53-bd9b-858a82589207.tmp.csv
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.669456f4-3d2c-4bcf-8470-cf7c6716ad31.tmp.txt
\\?\C:\ProgramData\Microsoft\Windows\WER\Temp\WER.c774a454-3995-46d9-87bf-0ac2e9f79e96.tmp.xml

These files may be available here:
NULL

Analysis symbol:
Rechecking for solution: 0
Report Id: 65bbfb31-978f-4445-9dea-2a71a62ffe3a
Report Status: 268435456
Hashed bucket: 176c8fa001a25831e9041f932b57d57f
Cab Guid: 0

[MILJW002]

Hi,

I was having the experience of when there was a cleanup task to remove old backup chains the server would become unresponsive. Still respond to PING, but unable to RDP, all remote services would be accessible, the remote management agents wouldn’t report, and if I tried to login to the console a black screen.

If I left if for enough hours it would usually come back. This was only related to backup jobs using ReFS volumes. So, I’m thinking this experience is an example of the ReFS code regression in Windows 2025. If I looked at the Event Log when I could eventually get in there was a large gap in the logs (covered the unresponsive period).

I have tried usual monthly updates, and currently running with some of the recommended registry entries (which I’ll call workarounds). I also removed some older backup chains a month or so ago to try and reduce the situation that triggers the ReFS bug.

I just checked the Event Log on that server and don’t see any examples of that error message you’ve listed.

[ChristophINV]

I got 14 more of those Events during the Update-Installation (affected processes are random, it happens basically on whatever is active at times during random user activity, so not just Veeam), but after the reboot for that September-Patchday, it stopped. Four now 70 minutes I could not induce any other 1001-Event from Windows Error-Reporting.

So it looks like, the Update actually did something. If that's even related to the ReFS-Issue, that's another thing.

I even felt like getting unpopular, starting a another Full-Backup-Test for a job with some throttling applied. Zero messages of that type yet. Memory Usage at 12.6/64 GB. Let's see, it took 20 hours the last time it hit me in the face. But IF those 1001-Leak-Errors are an indication...

[karsten123]

is it possible to add a note to the helpcenter documentation, to better not use Server 2025 for VBR and ReFS?

[ChristophINV]

OK, these 1001-Events regarding "RADAR_PRE_LEAK" seem not be relevant, as I see them on my 2019 Prod-Backup-Server without ReFS all the time also. Should have checked that earlier.

The new 2025-Server started spitting them again after 2 hours into the job but nevertheless the Full-Backup went thru after six hours without issues, RAM not exceeding 20 GB/64 (I put only so much in there, because I could in regards to the issue). But still unsure, if the September-Patchday actually fixed anything. That would require a weekend run for the initial full.

[BenM2024]

I can not confirm the positive message from the previous post....

Sadly nor can I entirely.

Today the server was only using 40Gb ram and 30% CPU when I logged in, but the Veeam Console refused to connect claiming "the server actively rejected the request". The RDP session on the server was responsive and behaving itself, the biggest user of CPU was the Kernel (I assume ReFS) at about 22%

Are you doing synthetic full backups as part of this, and has it used ReFS Fast Clone to perform synthetic full / merging yet?...
... Good luck!

Yup - uses FastClone for Synthetic fulls - can't check right now becasue its rebooting, which may take a while (previously, a commanded reboot has taken up to 4 hours to complete; obviusly I could just hold in the power button but that isn't best practise). if the machine hasn't rebooted by nealy home time the power button will be used!

Overall 3 days of backups, copies and testing restored machines is better than 0 days of any form of reliable backup activity - I would still call it a qualified win

[cbc-tgschultz]

To add another data point: I was also experiencing this issue. Veeam server was going rapidly to 100% CPU and becoming unresponsive while working with ReFS over iSCSI and synthetic fulls with fast clone.

In my case, the issue has not recurred since applying the registry changes further upthread and the september update.