Issue with ReFS on Windows Server 2025

The issue you're encountering is a known limitation of ReFS in certain high I/O, high-handle-count scenarios, particularly with VHD(X) containers. Given that you're on the latest Windows Server 2025 with patches, the underlying file system driver may still have scalability constraints in your specific environment.

The immediate and most effective solution is to migrate your FSLogix profile/container share to an NTFS volume. NTFS is more mature and robust under high concurrent file operations, especially with the random read/write patterns generated by FSLogix. Before migrating, ensure you have a validated backup of all VHD(X) files.

If migrating to NTFS is not immediately feasible, implement the following mitigations for ReFS:

Disable ReFS integrity streams on the volume. While this sacrifices data checksumming, it reduces metadata overhead. Use PowerShell:

Set-ItemProperty -Path "YourVolume:" -Name "IntegrityStreams" -Value $false

This must be done on an empty volume or after moving data off and reformatting.

Adjust the ReFS volume format settings. When formatting, use the largest allocation unit size (64KB) and disable short names. For an existing volume, you must reformat.

Optimize the SMB server settings on the host. In an elevated PowerShell, run:

Set-SmbServerConfiguration -AsyncHandleCount 1024 -Force

Set-SmbServerConfiguration -MaxMpxCount 1024 -Force

Set-SmbServerConfiguration -ServerHidden $true -AnnounceServer $false -Force

Then restart the server.

Increase the system's handle limit by adding a DWORD ObCaseInsensitive with value 1 under HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\kernel and reboot. Also, consider increasing the PendingFileRenameOperations value in the same registry path to 0x1000 (4096 decimal).

Monitor specific performance counters during high load to identify the bottleneck:

• ReFS\Metadata I/O Latency
• ReFS\Metadata Operations per Second
• System\File Read Operations/sec
• System\Processes\Handle Count for System and FsFilter processes

If the instability persists, engage Microsoft Support with a full memory dump of the server during a freeze and the ReFS operational logs (Event ID 129, 130, 131 from Microsoft-Windows-ReFS/Operational). There may be a known hotfix or driver update for your specific storage controller.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to ACCEPT ANSWER then. Should you have more questions, feel free to leave a message. Have a nice day!

VP

Moving VHDX files to NTFS is not a good solution. It doesn't work correctly.

We need to diagnose why NTFS is failing, as it is the foundational, supported file system for this workload. I suppose the issue then is likely not with NTFS itself, but with permissions, SMB configuration, or FSLogix settings that are being exposed or handled differently on the NTFS volume. Please verify the following on the NTFS share: the share permissions (Everyone or the specific computer object with Full Control) and NTFS permissions (the same group needing Full Control on the root and subfolders) must be explicitly set. Crucially, disable Access-Based Enumeration on the share if it is enabled, as this can cause unexpected access failures. Also, ensure the FSLogixAppsRules registry key or any external filter driver is not blocking access to the new location.

At the same time, to address the ReFS instability, the most targeted mitigation is to disable integrity streams, as previously mentioned, but this requires a reformat. If the system is freezing, collect a live kernel memory dump during the freeze using notmyfault.exe from Sysinternals, or configure a crash dump via NMI if the system is completely non-responsive. The primary logs to extract before a reboot are from Microsoft-Windows-ReFS/Operational and Microsoft-Windows-SMBClient/Operational. The specific pattern of handles and locks in these logs will pinpoint the contention.

Given the severity and that both file system paths are problematic, this points to a potential underlying issue with the storage stack, filter drivers (like antivirus), or a specific Windows Server 2025 build bug. As a direct action, please run fltmc filters and list all active file system filter drivers. Temporarily uninstall any third-party storage or security filters for testing. Also, validate the storage driver and firmware for your array or disks are certified for Server 2025.

Anyway, since a production environment can't tolerate instability, engaging Microsoft Support with the data you collect is the fastest path to a root cause. They can analyze the dumps and logs against known issues and potentially provide a hotfix. of course it's in case you've tried all methods above and still fail. If this answer gets you more insight into the issue, it's appreciated to accept it so that other people sharing the same problem as yours would benefit too. THanks!

VP

Permissions are good. But still slowness. In other way, way have move from FSLOGIX to Citrix Container profile profile and this one doesn't support NTFS.

Why we have move from FSLOGIX due to limitation of mangement from Citrix.

I will test the different settings to do on ReFS. But have seen better performance of ReFS on Windows Server 2022. Could you explain the reason ?

Hi,

It is important to clarify a key architectural detail regarding your migration: Citrix Profile Management absolutely supports NTFS. The limitation you are perceiving is that NTFS lacks Block Cloning, an ReFS-exclusive feature that dramatically accelerates VHDX differencing disk merges. While NTFS works, it will feel slower during profile compaction because it cannot perform these metadata-only operations, but it is fully supported if you ever need to fall back.

Regarding your observation that ReFS performed better on Server 2022, this is a known friction point with early Server 2025 adoption. Server 2025 utilizes a newer ReFS driver stack (likely v3.14+) that is significantly more aggressive with metadata checkpointing and flushing. In high-concurrency environments, this newer code path often conflicts with storage filter drivers (like Antivirus or EDR agents) that were optimized for the Server 2022 kernel, leading to the "freezing" you experience as the system locks up waiting for I/O confirmation.

Since you are staying on ReFS to leverage Block Cloning, you must manually strip away the overhead that is choking the 2025 driver. The single most critical change is to disable Integrity Streams on your profile data folder using the PowerShell command Set-FileIntegrity -FileName "D:\YourProfilePath" -Enable $False; having this enabled on VHDX files causes a "write amplification" loop that creates instability. You should also verify via fltmc instances that your antivirus isn't inspecting the internal block commits of the containers, and consider setting the registry DWORD RefsEnableLargeWorkingSetTrim to 0 in HKLM\SYSTEM\CurrentControlSet\Control\FileSystem to force the server to keep ReFS metadata in RAM rather than constantly flushing it to the disk.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer then. Should you have more questions, feel free to leave a message. Have a nice day!

VP