SOLVED

ReFS volume appears RAW (version doesn't match expected value) after Windows Update

Brass Contributor

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.

87 Replies

@stephc_msft I will look into spinning up a backup of our Exchange server in our lab and test the disable hotplug solution. Thanks again for the help and clarification!

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. ♥
We saw the same issue in our environment. Thank you removing those 2 updates resolved our issue.

Has anyone verified that turning off hotplug drives in VMWare config enables Win 212R2 server to get the latest updates? 

@ABeachy We received the update via SCCM deployment to our server collection.

We had uninstall both KB5009595 and KB5009624 on our 2012r2 server. After the server rebooted the ReFS volume worked again with no data loss.

@JGarcia1 

Another hour of unexpected downtime to a mission critical server.  Can MS stop pushing this update to my server please?

I had this issue now with REFS / RAW volume on my Exchange DB vol for the second time in a month.  I'm running Exchange 2016, Win2012R2 box.  I had even had the Windows Update Service Disabled to stop the server from rebooting to install updates just from logging into it.  It rebooted to install updates anyway and installed this bug for the second time.  I'm migrating off this box as quick as possible...

@ngruendl Can you confirm if you are running on VMWare ? Have you tried the vmware solution of disabling hotplug? As that is the only solution for WS2012R2 using refs on disks that are showing characteristics of 'removal' (like VMWare presents)

Cant comment on why updates got applied even after you were 'disabling' updates.
@stephc_msft that is my question. Does disabling hotplug in VMWare config allow the installation of the new updates and not break ReFS on WS2012R2? Has anyone actually verified this?

@ABeachy 

I am running VMWare.  I have not tried the fix though.  It might be a while before I have a maintenance window to do this.

I was finally able to test this in my lab with my Exchange 2016 server running on Server 2012 R2. I was able to apply the VMware workaround and install the patch without issue. Note that I have not completed this task on my live server yet, but I am confident it will work at this point.

1. Shutdown the server.
2. Follow the steps in this vmware KB article https://kb.vmware.com/s/article/1012225
3. Power up the machine (it took about 8 minutes for all of the virtual hardware to register with the server, but this may have been because I powered up the server for the first time in my lab which has different host hardware.)
4. Install the security patches (I ended up installing the February security patches)
5. Reboot.
6. Confirm that your REFS drives are operational.
7. Confirm that you can migrate the VM to a different host for HA purposes.
I have ESXi7.0 u2 on my hosts and Guest windwos 2012r2 VM's.

These steps also helped Windows 2012r2 VM to recognize the ReFS Volume.
1. Shutdown the server.
2. Follow the steps in this vmware KB article https://kb.vmware.com/s/article/1012225
3. Power up the machine

Thanks @E3SMC

This workaround works with february updates , 20212r2 refs with exchange 2016, is this going to be fix by vmware/microsoft? 

@JGarcia1 

@stephc_msft So ReFS version 3.1 is not affected by this and the 2022-02 updates can safely be installed, correct?

Yes, refs v3.1 on WS2016 will be ok after Feb updates. Note that if still using v1.2 refs disk on WS2016 or later, then the v1.2 disks will still be affected, it they are detected as removable/hoypluggable.
The issue still persists for some, and it will reappear in the future whenever old volumes are mounted. This is quite annoying, as ReFS was supposed to be the best long-term preservation solution to contrast bitrot, etc.

This thread started with my post for a scenario with Windows Server 2019 and a ReFS 1.2 volume (on storage space, not removable). This has not been solved. It was not fixed with the January hotfix, nor in February (tried that, had to uninstall updates again). The "solution" was to copy the data to a new ReFS volume.

@stephc_msft remember we had a direct exchange, also using your diagnostic tool to confirm that the volume was not flagged as removable.

By now, everyone who was affected probably already copied their data from ReFS 1.x to a newer version. Still, as many could be affected in the future they could show a helpful error message rather than volumes turning RAW, which also misleads many into thinking that the data has been lost forever (already happened this year, as seen on various other forums).

@stephc_msft I lost two ReFS v1.2 volumes with 4TB of irreplaceable data on each attached to a Win10 Pro machine. These volumes were created when it was allowed and I kept them because there was no indicator of any kind in all these years that this is not a supported configuration. Neither set of drives is removable. None of the KB's mentioned in this thread here seem to exist on Win10 Pro. Can you please advise what can be uninstalled to recover the data?

 

Any help will be appreciated.

@AM-4566 you could try and go to Windows Update/Update history and uninstall any updates from January 2022 and later, and then pause updates to continue working on the issue. Then RoboCopy (or similar) the data to a new volume, which should be NTFS or a newer version of ReFS.

Agreed. Try removing Jan22 update, and any later updates, and confirm if the volumes are then accessable.
If they are still showing RAW then it is likely you have some other real corruption issues .
There are some utilities (including refsutil.exe from later OS versions) and 3rd party tools like www.r-studio.com that understand refs and can attempt to scan and copy out any data it can find.