Microsoft seems to think this is no longer an issue?

[riverar]

I resurfaced your Reddit thread on this announcement
https://techcommunity.microsoft.com/blog/windowsservernewsandbestpractices/announcing-refs-boot-for-windows-server-insiders/4496592

And a Microsoft employee replied:

chcurlet-msft Mar 23, 2026

This issue was due to errors in the original script linked in the post. The script has since been corrected. Please check out my latest comments on the Reddit post for more details.

I can't find any comments from them so now I'm very confused. I found the comments, I'm just bad at Reddit.

Screenshots

Blog comments

Reddit

[Borgquite]

Thanks. A short while ago on the Reddit thread someone posted a suggestion to include some additional steps with Disconnect-VirtualDisk and Connect-VirtualDisk and said it resolved the corruption issues for them. I couldn't replicate the fix myself at first, so asked them to submit their changes - unfortunately they submitted a complete refactor of the code which left me unsure if it was actually fixed or they had changed the flow to accidentally mask the issue. I asked them if they'd be willing to submit their changes within the existing code flow, but they didn't want to spend the time doing so.

In the end I had another go at putting the suggestions in place (with no help!) and it does seem that it may have resolved the corruption issues after a few test runs. But to be honest I don't know how much of this was in the script, and how much was down to Microsoft fixing stuff in recent ReFS updates. I am not the only one who previously saw ReFS Integrity Streams data corruption issues, and a Microsoft PM previously indicated there was work to be done, so I'm not sure it was all just down to the script. However I've not got the time to do proper testing on different Windows / Windows Server / ReFS versions, or to see if the error logging issues are completely resolved (my brief testing results were unclear), and I don't think it would be responsible to declare the problems completely fixed until that's happened.

It is possible that some/most/all of these issues are fixed in the latest versions. The script is freely available so anyone can verify for themselves according to individual risk appetite. I am certain that there were issues raised by this script that Microsoft have had to fix - the corruption event logging issues at least - and I think repair logging issues may also still be broken. It would be great if Microsoft have fixed them in later releases - but it would be more helpful if they could acknowledge this in some official release notes (with version numbers, which OSes are covered), rather than in a random comment on the Tech Community and Reddit, implying that all the issues were just down to script errors. Trust me, they were not - nor were Microsoft the ones that reported the issue above.

I'd be interested to see the Reddit comment from the MS employee as this is the only contact I've had for many years - can you share a link please, as I can't find it either!

[Borgquite]

PS If the above comment feels a bit world weary and defeatist, that's because I am. Spending 5 years trying to get Microsoft interested in considering and addressing potentially serious issues in their product, including concerns that they may be silently corrupting data (and failing to correctly log disk corruption and repairs was definitely an issue at some point), has that sort of effect. I don't really have any interest in defending them any more even if they reckon it's now all good. A thank you would be nice.

I had a great experience with a single Microsoft PM who acknowledged that there were issues which they had to work on (therefore it's not pleasant to be gaslit that 'it was all errors in the script') but once he left it's been customer service hell, like most of Microsoft nowadays. I wouldn't use ReFS Integrity Streams anyway now because of how awful I would expect reporting and resolving any future data integrity issues they might introduce would be.

[Borgquite]

My prerequisite for updating the post now would be to do testing on each currently supported version of Windows, detailing which versions are fixed, and to what extent, and which are not. This is actually Microsoft's job and should be in a set of release notes somewhere, hence why I'm not in any rush to do so, but would be nice to close the loop if I get the chance sometime.

[riverar]

Hey Chris, I'm Rafael and have a long history working with Microsoft externally. Let me catch up on the script and we'll close the loop here. This is just nuts.

I can run the test matrix for you and start getting new data.

Adding @shanselman who can help with routing internally.

[riverar]

Also looping in @crutkas, believe his Dev Drive feature team is impacted by ReFs bugs and will at least be curious here...

[Borgquite]

Thanks @riverar. If you do some testing, I'd suggest focussing on the two event logging issues - failing to consistently generate 'The file system detected a checksum error and was not able to correct it.' errors, and incorrectly generating 'The file system detected a checksum error and was able to correct it.' even though the error was not corrected. I would also like to tell people in which (supported) versions of Windows 11 and Windows Server each issue is fixed, or not fixed, since the PM I spoke to before, told me that it was unlikely that any fixes to ReFS would be back ported.

Really appreciate you taking the time and offering to share some of the work and responsibility here, that's what's felt lacking :)

[crutkas]

Asking around.

[Borgquite]

Just managed to locate the Reddit comment from chcurlet-msft (it was hidden under another comment deleted by the moderator)

https://www.reddit.com/r/DataHoarder/comments/scdclm/comment/oc3junt/?utm_source=share&utm_medium=web3x&utm_name=web3xcss&utm_term=1&utm_content=share_button

If you're talking to Microsoft people I'd love to know why the Feedback Hub issue was removed/deleted without notification. It's not the first time I've experienced this sort of thing with Microsoft's 'feedback' portals, but this was probably the last straw when it came to my whole experience and willingness to work within Microsoft's feedback process, as it really just summed up the atricious attitute which Microsoft treat customer feedback with these days.

[Borgquite]

Done some testing in Server 2019 (ReFS 3.4, latest updates) - it still frequently fails to report corruption in the Event Log. I am not seeing any repair issues.

[riverar]

If you're talking to Microsoft people I'd love to know why the Feedback Hub issue was removed/deleted without notification.

Feedback Hub retention policy is 18 months, last time I asked.

[Borgquite]

Feedback Hub retention policy is 18 months, last time I asked.

Hold on, so if there's a long standing problem that Microsoft have yet to address, it just gets automatically wiped out, and we have to submit it again?

And anyone who reported the issue never gets told if it is eventually addressed?

That's atrocious customer service and a great way to incentivise ignoring issues. Whoever decided that needs to find another job.

[Borgquite]

Same experience testing in Server 2022 (ReFS 3.7, latest updates) - it did not seem to report corruption, or repair in the Event Log at all. No repair issues so far.

[riverar]

Windows Server 2025 Insider Build 29558.1000

[03/30/2026 09:25:29] Starting script on Microsoft Windows Server 2025 Datacenter Dev (OS Build 29558.1000)...
[03/30/2026 09:25:30] Creating Mirror ReFS volume with 3 VHDs and 1 Disk Redundancy in Windows Storage Spaces...
[03/30/2026 09:25:45] Setting virtual disk to manual attach to allow disconnection...
[03/30/2026 09:25:45] Enabling ReFS Integrity Streams on ReFS volume with Storage Spaces...
[03/30/2026 09:25:45] Displaying refsinfo for newly created volume...
REFS Volume Serial Number :                0xa09adb899adb59fc
REFS Volume Version :                      3.14
REFS Driver Maximum Supported Version :    3.15
Number Sectors :                           0x00000000009e0000
Total Clusters :                           0x000000000013c000
Free Clusters  :                           0x00000000000eaef4
Total Reserved :                           0x0000000000025020
Bytes Per Sector  :                        512
Bytes Per Physical Sector :                4096
Bytes Per Cluster :                        4096
Fast Tier Data Fill Percentage :           0.0%
Slow Tier Data Fill Percentage :           0.0%
Fast Tier to Slow Tier Rate (Clusters/s) : 0
Metadata Checksum Type :                   CHECKSUM_TYPE_CRC64
Data Checksum Type :                       CHECKSUM_TYPE_CRC32

[03/30/2026 09:25:45] Creating text file 'T:\test1.0001.txt' with test file contents 'Corrupt_me_1 0001'...
[03/30/2026 09:25:45] Creating text file 'T:\test1.0002.txt' with test file contents 'Corrupt_me_1 0002'...
[03/30/2026 09:25:45] Creating text file 'T:\test1.0003.txt' with test file contents 'Corrupt_me_1 0003'...
[03/30/2026 09:25:50] Writing volume cache to ensure all data is flushed to virtual disks...
[03/30/2026 09:25:50] Disconnecting virtual disk so that all data is flushed to the virtual disks...
[03/30/2026 09:25:51] Dismounting '1.vhdx' to generate corruption...
[03/30/2026 09:25:56] Dismounting '2.vhdx' to generate corruption...
[03/30/2026 09:26:01] Dismounting '3.vhdx' to generate corruption...
[03/30/2026 09:26:06] Searching '3.vhdx' for 'Corrupt_me_1'...
[03/30/2026 09:26:07] Found 'Corrupt_me_1' at position 301989888 - corrupting following character from ' ' to '!'...
[03/30/2026 09:26:07] Found 'Corrupt_me_1' at position 304087040 - corrupting following character from ' ' to '!'...
[03/30/2026 09:26:07] Found 'Corrupt_me_1' at position 411041792 - corrupting following character from ' ' to '!'...
[03/30/2026 09:26:07] Scanning '1.vhdx' to verify uncorrupted or corrupted data before repair...
[03/30/2026 09:26:08] Scanning '2.vhdx' to verify uncorrupted or corrupted data before repair...
Corrupt_me_1 0002
Corrupt_me_1 0003
Corrupt_me_1 0001
[03/30/2026 09:26:11] Scanning '3.vhdx' to verify uncorrupted or corrupted data before repair...
Corrupt_me_1!0002
Corrupt_me_1!0003
Corrupt_me_1!0001
[03/30/2026 09:26:12] Remounting '1.vhdx' to test Integrity Streams corruption detection & repair...
[03/30/2026 09:26:17] Remounting '2.vhdx' to test Integrity Streams corruption detection & repair...
[03/30/2026 09:26:23] Remounting '3.vhdx' to test Integrity Streams corruption detection & repair...
[03/30/2026 09:26:28] Reconnecting virtual disk...
[03/30/2026 09:26:28] Waiting for Storage Pool to reach Healthy status...

HealthStatus OperationalStatus ReadOnlyReason
------------ ----------------- --------------
Healthy      OK                None


[03/30/2026 09:26:28] Attempting to read 'T:\test1.0001.txt' - should be able to read without errors...
Corrupt_me_1 0001
[03/30/2026 09:26:28] Attempting manual scrub / repair on 'T:\test1.0001.txt'...
[03/30/2026 09:26:28] Attempting to read 'T:\test1.0002.txt' - should be able to read without errors...
Corrupt_me_1 0002
[03/30/2026 09:26:28] Attempting manual scrub / repair on 'T:\test1.0002.txt'...
[03/30/2026 09:26:28] Attempting to read 'T:\test1.0003.txt' - should be able to read without errors...
Corrupt_me_1 0003
[03/30/2026 09:26:28] Attempting manual scrub / repair on 'T:\test1.0003.txt'...
[03/30/2026 09:26:33] Reading event logs to verify corruption & any fixes are logged in System Event log...
Get-WinEvent : No events were found that match the specified selection criteria.
At C:\Users\Administrator\desktop\Test-ReFSDataCorruption.ps1:221 char:1
+ Get-WinEvent -FilterHashtable @{ StartTime=$scriptstarttime; LogName= ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEventCommand

[03/30/2026 09:26:34] Writing volume cache to ensure all data is flushed to virtual disks...
[03/30/2026 09:26:34] Disconnecting virtual disk so that all data is flushed to the virtual disks...
[03/30/2026 09:26:34] Dismounting '1.vhdx' to verify whether corruption was correctly detected & repaired on all drives...
[03/30/2026 09:26:34] Dismounting '2.vhdx' to verify whether corruption was correctly detected & repaired on all drives...
[03/30/2026 09:26:34] Dismounting '3.vhdx' to verify whether corruption was correctly detected & repaired on all drives...
[03/30/2026 09:26:34] Scanning '1.vhdx' for uncorrupted or corrupted data - all except set 0 should be uncorrupted...
[03/30/2026 09:26:35] Scanning '2.vhdx' for uncorrupted or corrupted data - all except set 0 should be uncorrupted...
Corrupt_me_1 0002
Corrupt_me_1 0003
Corrupt_me_1 0001
[03/30/2026 09:26:37] Scanning '3.vhdx' for uncorrupted or corrupted data - all except set 0 should be uncorrupted...
Corrupt_me_1 0002
Corrupt_me_1 0003
Corrupt_me_1 0001

[Borgquite]

@riverar Same as me then. This line should contain one event log entry per corrupted file, to meet the documented behaviour 'ReFS will record all corruptions in the System Event Log, and the log will reflect whether the corruptions were fixed.'. It should not return an error.

[03/30/2026 09:26:33] Reading event logs to verify corruption & any fixes are logged in System Event log...
Get-WinEvent : No events were found that match the specified selection criteria.
At C:\Users\Administrator\desktop\Test-ReFSDataCorruption.ps1:221 char:1
+ Get-WinEvent -FilterHashtable @{ StartTime=$scriptstarttime; LogName= ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (:) [Get-WinEvent], Exception
    + FullyQualifiedErrorId : NoMatchingEventsFound,Microsoft.PowerShell.Commands.GetWinEventCommand

It works sometimes if you keep trying, but not consistently.

Knowing when corruption is detected and whether it's been repaired correctly or not is obviously critical for Integrity Streams to be at all useful in production.

[riverar]

Windows Server 2025 Insider Build 29558.1000 (second run)

[03/30/2026 09:46:12] Starting script on Microsoft Windows Server 2025 Datacenter Dev (OS Build 29558.1000)...
[03/30/2026 09:46:12] Creating Mirror ReFS volume with 3 VHDs and 1 Disk Redundancy in Windows Storage Spaces...
[03/30/2026 09:46:24] Setting virtual disk to manual attach to allow disconnection...
[03/30/2026 09:46:25] Enabling ReFS Integrity Streams on ReFS volume with Storage Spaces...
[03/30/2026 09:46:25] Displaying refsinfo for newly created volume...
REFS Volume Serial Number :                0x9276be2476be094d
REFS Volume Version :                      3.14
REFS Driver Maximum Supported Version :    3.15
Number Sectors :                           0x00000000009e0000
Total Clusters :                           0x000000000013c000
Free Clusters  :                           0x00000000000eaebc
Total Reserved :                           0x0000000000025048
Bytes Per Sector  :                        512
Bytes Per Physical Sector :                4096
Bytes Per Cluster :                        4096
Fast Tier Data Fill Percentage :           0.0%
Slow Tier Data Fill Percentage :           0.0%
Fast Tier to Slow Tier Rate (Clusters/s) : 0
Metadata Checksum Type :                   CHECKSUM_TYPE_CRC64
Data Checksum Type :                       CHECKSUM_TYPE_CRC32

[03/30/2026 09:46:25] Creating text file 'T:\test1.0001.txt' with test file contents 'Corrupt_me_1 0001'...
[03/30/2026 09:46:25] Creating text file 'T:\test1.0002.txt' with test file contents 'Corrupt_me_1 0002'...
[03/30/2026 09:46:25] Creating text file 'T:\test1.0003.txt' with test file contents 'Corrupt_me_1 0003'...
[03/30/2026 09:46:30] Writing volume cache to ensure all data is flushed to virtual disks...
[03/30/2026 09:46:30] Disconnecting virtual disk so that all data is flushed to the virtual disks...
[03/30/2026 09:46:30] Dismounting '1.vhdx' to generate corruption...
[03/30/2026 09:46:35] Dismounting '2.vhdx' to generate corruption...
[03/30/2026 09:46:40] Dismounting '3.vhdx' to generate corruption...
[03/30/2026 09:46:45] Searching '3.vhdx' for 'Corrupt_me_1'...
[03/30/2026 09:46:46] Searching '2.vhdx' for 'Corrupt_me_1'...
[03/30/2026 09:46:47] Found 'Corrupt_me_1' at position 249561088 - corrupting following character from ' ' to '!'...
[03/30/2026 09:46:47] Found 'Corrupt_me_1' at position 253755392 - corrupting following character from ' ' to '!'...
[03/30/2026 09:46:47] Found 'Corrupt_me_1' at position 457179136 - corrupting following character from ' ' to '!'...
[03/30/2026 09:46:47] Scanning '1.vhdx' to verify uncorrupted or corrupted data before repair...
Corrupt_me_1 0003
Corrupt_me_1 0001
Corrupt_me_1 0002
[03/30/2026 09:46:49] Scanning '2.vhdx' to verify uncorrupted or corrupted data before repair...
Corrupt_me_1!0003
Corrupt_me_1!0001
Corrupt_me_1!0002
[03/30/2026 09:46:50] Scanning '3.vhdx' to verify uncorrupted or corrupted data before repair...
[03/30/2026 09:46:51] Remounting '1.vhdx' to test Integrity Streams corruption detection & repair...
[03/30/2026 09:46:56] Remounting '2.vhdx' to test Integrity Streams corruption detection & repair...
[03/30/2026 09:47:02] Remounting '3.vhdx' to test Integrity Streams corruption detection & repair...
[03/30/2026 09:47:07] Reconnecting virtual disk...
[03/30/2026 09:47:07] Waiting for Storage Pool to reach Healthy status...

HealthStatus OperationalStatus ReadOnlyReason
------------ ----------------- --------------
Healthy      OK                None


[03/30/2026 09:47:07] Attempting to read 'T:\test1.0001.txt' - should be able to read without errors...
Corrupt_me_1 0001
[03/30/2026 09:47:07] Attempting manual scrub / repair on 'T:\test1.0001.txt'...
[03/30/2026 09:47:07] Attempting to read 'T:\test1.0002.txt' - should be able to read without errors...
Corrupt_me_1 0002
[03/30/2026 09:47:07] Attempting manual scrub / repair on 'T:\test1.0002.txt'...
[03/30/2026 09:47:07] Attempting to read 'T:\test1.0003.txt' - should be able to read without errors...
Corrupt_me_1 0003
[03/30/2026 09:47:07] Attempting manual scrub / repair on 'T:\test1.0003.txt'...
[03/30/2026 09:47:12] Reading event logs to verify corruption & any fixes are logged in System Event log...


   ProviderName: Microsoft-Windows-ReFS

TimeCreated           Id LevelDisplayName Message
-----------           -- ---------------- -------
3/30/2026 9:47:07 AM 132 Warning          The file system detected a checksum error and was able to correct it. The ...
3/30/2026 9:47:07 AM 132 Warning          The file system detected a checksum error and was able to correct it. The ...
3/30/2026 9:47:07 AM 132 Warning          The file system detected a checksum error and was able to correct it. The ...


[03/30/2026 09:47:12] Writing volume cache to ensure all data is flushed to virtual disks...
[03/30/2026 09:47:12] Disconnecting virtual disk so that all data is flushed to the virtual disks...
[03/30/2026 09:47:12] Dismounting '1.vhdx' to verify whether corruption was correctly detected & repaired on all drives...
[03/30/2026 09:47:12] Dismounting '2.vhdx' to verify whether corruption was correctly detected & repaired on all drives...
[03/30/2026 09:47:12] Dismounting '3.vhdx' to verify whether corruption was correctly detected & repaired on all drives...
[03/30/2026 09:47:13] Scanning '1.vhdx' for uncorrupted or corrupted data - all except set 0 should be uncorrupted...
Corrupt_me_1 0003
Corrupt_me_1 0001
Corrupt_me_1 0002
[03/30/2026 09:47:14] Scanning '2.vhdx' for uncorrupted or corrupted data - all except set 0 should be uncorrupted...
Corrupt_me_1 0003
Corrupt_me_1 0001
Corrupt_me_1 0002
[03/30/2026 09:47:17] Scanning '3.vhdx' for uncorrupted or corrupted data - all except set 0 should be uncorrupted...