Forum Discussion
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 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.
- We ran into this on a Server 2012 server and had to uninstall both KB5009595 and KB5009624 before our drives came back.
Same problem here on Windows 2012R2. We have to uninstall both, KB5009595 and KB5009624. After uninstallation our ReFS File Sytem came back!
- 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. ♥ 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-7f64d4d9a8cd- 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.
Microsoft 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!
- 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.
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
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?
Has anyone verified that turning off hotplug drives in VMWare config enables Win 212R2 server to get the latest updates?
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
