Forum Discussion
Solved
ReFS volume appears RAW (version doesn't match expected value) after Windows Update
After Windows Update last night, Windows Server 2019 wouldn't mount a storage space volume as ReFS (it appears as RAW). The error in the ReFS event log is "ReFS failed to mount the volume. Version 1.2 doesn't match expected value 3.4" No issues that I can see at the storage space level (it is a mirrored disk). The volume was working fine before Windows Update and the reboot. Another ReFS volume still works fine after the update.
Any clues? I could not find this error mentioned anywhere else. Thanks.
I solved this by uninstalling KB5009557. The ReFS volume came back working as it should, instead of appearing as RAW.
Update: since even the February 2022 Windows Update bricks ReFS in the same way, and hints from Microsoft are that ReFS 1.x is no longer supported, we copied everything to new disks, upgrading ReFS from 1.2 to 3.4 in the process. Such a (manual) ReFS upgrade should be the solution that everyone needs, allowing to re-enable Windows Update.
I have been look for an answer to this for over 2 years now and it looks I have found a light at the end of a long tunnel
https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/refsutil
I have been running Storage spaces since day one and I would have thought that MS would have built into the OS upgrade process a method to upgrade there own ReFS drives during the upgrade from OS to OS but I guess not.
But they do have this Util and I am now running it with the hope of recovery.
With all respect, thepierce I don't think that ReFSUtil is the solution to the problem discussed in this thread, which boils down to a ReFS version incompatibility. ReFSUtil won't do a major in-place ReFS version upgrade.
The best way I found to solve the problem is to copy (e.g. with RoboCopy) all data from the old ReFS volume to a newly formatted ReFS volume (i.e. newer ReFS version), using an operating system where the old ReFS version is still supported.It is of course regrettable that this issue came upon us with no checks or warnings and that the workaround requires new disks, and even more so that some people were led to believe that their data was lost, and that some managed to corrupt the data in the attempt of "recovering" it.
ReFS is a good file system, and because it is fairly new (compared to NTFS) I can understand that features are sometimes added that require a newly formatted ReFS volume. These constant breaking changes may even be a reason why they pulled it from mainstream Windows 10/11, though I see work being done to bring it back. What is less understandable is the fact that the deprecation of older ReFS versions comes with no warnings upon a simple Windows Update or upgrade. This happened in 2022 with KB5009557, KB5009624, etc. on the Windows Server side, and then again on some client systems who were prompted to update their Windows 10 to Windows 11. These are perfectly recognizable situations. If a dialog appeared telling the user what they need to do before a volume disappears, we would not be spending so much time on these threads 🙂Please, Microsoft, give ReFS the same love you gave NTFS, which in its days had in-place conversion support, while never suffering from breaking changes that (without warning) required copying entire volumes just to keep accessing the data.
- > I don't think that ReFSUtil is the solution to the problem discussed in this thread, which boils down to a ReFS version incompatibility.
I agree. I tried a few ReFS recovery tools before I was able to roll back the KB that caused this mess and they are all terrible - searching for file signatures in volumes affected by this issue is very ineffective. I had a few TBs of data and recovery tools would claim they found 2-3 times of the original amount and they restored deleted files, confused directories, etc. I didn't try refsutil, but anything looking for signatures would probably be just as terrible.
Unlike many in this thread, I used ReFS on Win10, which was available in the original Win10 distribution. It took time to find that KB to uninstall, but once I did, I got my volumes back. Finding and uninstalling that KB is the best course of action, although it might be tricky after so many updates piling up since.
For me, this has just reared its head when installing KB5014738 (2022-06 Security Monthly Quality Rollup). The exact symptoms as above, showing a RAW partition on an ReFS volume on Windows Server 2012 R2 on the Xen HV. I asked the HV host to make changes to the configuration of our VM to be xe vm-param-set uuid=<vm_uuid of the problematic vm> platform:device-model=qemu-trad but they refused so I have had to rollback the install of this KB.
No idea why this didn't impact us the first time round but just in case anyone comes across this thread and doesn't see their KB listed.
stephc_msft Your suggested command to see the ReFS version number doesn't seem to work on Server 2012 R2. Is there a suitable command for this version instead of fsutil fsinfo refsinfo x:
- Thanks for the info on Xen HV.
WS2012R2 does not have the refsinfo option in fsutil, but doesnt matter too much, as if using ReFS on 2012R2 it will always be ReFS V1.2
If you can examine the first sector of the ReFS volume with a disk/hex editor then the version number is 'obvious' at offset 28 hex
Has anyone verified that turning off hotplug drives in VMWare config enables Win 212R2 server to get the latest updates?
- I'm running Windows 10 on a machine that I set up with Storage Spaces/ReFS nine years ago. I can relate to the despair - when I booted my PC yesterday and saw my archive volume appearing as a RAW volume. I tried various combinations of Windows Update removals/reinstalls/hotfixes described above, cold boots as recommended on another thread, even ReFSUtil.exe salvage - all with no success.
I'm so thankful I remembered that, years ago, I had used IsoBuster (https://www.isobuster.com/) to get files off of a DVD. Turns out, it supports ReFS!! I have access to all my files again. Huge thanks to the developer of IsoBuster for all his efforts in building and maintaining that incredible tool over the years. ♥ Updated three Server 2019 Datacenter with direct attached ReFS Volumes (VMware) two days ago with the "fixed" updates. Two servers went fine. Third not. ReFS volume RAW. Uninstalled KB5010791 on this server. Took round about 20 minutes. After uninstall ReFS volume was OK again. Don't know what to say....
Edit:
On all three servers hotplug isn't disabled!
Will try to disable hotplug on the affected server next weekend and try to install update KB5010791 again.
But why the issue does not occure on the two other servers with hotplug enabled too?
The Issues is caused by the kb5005959 on Windows 2012(r2) Server with ReFS-Formatted disks.
Uninstalling the patch and rebooting fixes the problem.
Best,
Noël
- Can definitely confirm that Server 2019 Datacenter is still experiencing the ReFS issue after updating, and the only other patch that appears in Updates is KB5010791. It doesn't solve the issue either.
Can't believe it's been this long and there still isn't a fix for this on 2019 when it's obviously an issue (whether MS wants to admit it or not).
The only fix so far for 2019 is to uninstall both KB5010791 and KB5009557. And then not run Windows Updates again until it's finally acknowledged and fixed.- just installed KB5010791 to fix ReFS issue. Did not solve the problem on Server 2019. Volume still is not available.
Seems like a joke that "The Resilient File System (ReFS) is Microsoft's newest file system, designed to maximize data availability, scale efficiently to large data sets across diverse workloads, and provide data integrity with resiliency to corruption" is getting useless due to an until now unfixed MS Bug.- Possible solution to fix this issue:
I wondered about the fact that only "removable" devices were affected.
So i changed the "devices.hotplug" value in VM config to "false".
This is dissabling the hotplug for the VM.
After starting the server 2019 my ReFS HD was back.
Simple to do and i do not see big side effects.
Hope it helps somebody.
A day after the other out-of-band updates, KB5010791 was made available for Windows Server 2019 as well. However, it did not resolve the ReFS issue for me. I uninstalled KB5010791 and then KB5009557, and the broken ReFS volume mounted fine again (it is on a storage space, not removable media).
https://support.microsoft.com/en-us/topic/january-18-2022-kb5010791-os-build-17763-2458-out-of-band-43697313-d8e0-4918-b6df-7f64d4d9a8cdMicrosoft just released a series of out-of-band updates (KB5010790 for Windows Server 2016, KB5010793 for Windows 10, KB5010795 for Windows 11, KB5010796 for Windows Server 2022, KB5010794 for older systems, etc.) to address the ReFS issue. For some reason they still claim the bug to be limited to removable media, even if that was not the case for me and others.
Alas, I could not find an out-of-band update for Windows Server 2019. So far, no KB page and no Windows Update showing up. ReFS is still broken by re-applying the current (January 18) KB5009557.
- Thanks for the follow-up much appreciated!
- I will tag along in the hope if Pernille-Eskebo will acknowledge or come with a mitigation for it.
- It seems to be a known issue for the 2022-01 patches.
