ReFS Volume Directory Structure Corruption (Event ID 133)

Question

ReFS Volume Directory Structure Corruption (Event ID 133)

Samuel Parker 40

Hyper-V hosts are repeatedly logging ReFS Event ID 133 (File System Check), indicating corrupted metadata allocations on a critical VM backup volume. What is the correct procedure for running ⁠refsutil salvage⁠ to extract uncorrupted VM images from a degraded ReFS volume?

0 comments

2 answers

Your answer

Answer 1

For a degraded ReFS volume showing corruption symptoms such as Event ID 133, use refsutil salvage to copy recoverable files to a different healthy volume instead of attempting in-place repair.

Confirm the scenario fits ReFS corruption.
- Event ID 133 and a RAW or inaccessible volume are listed as common signs of ReFS corruption.
- On Hyper-V backup storage, ReFS corruption can also affect VHD, AVHDX, or configuration files.
Use a supported operating system.
- refsutil salvage is supported on:
  - Windows 10 Pro for Workstations or later
  - Windows Server 2019 or later
Prepare three locations.
- <source volume>: the damaged ReFS volume, such as E:
- <working directory>: a folder for logs and progress data, not on the source volume
- <target directory>: a different healthy volume where recovered files will be copied, not on the source volume
Start with a quick automatic salvage.
```
   refsutil salvage -QA E: C:\Temp D:\Recovered -x
```
- -QA runs a Quick Scan Phase followed by a Copy Phase.
- -x forces the volume to dismount first if necessary. This invalidates open handles to the volume.
- This is the faster first pass and minimizes recovery of outdated files, directories, or volumes.
If the quick pass does not recover what is needed, run a full automatic salvage.
```
   refsutil salvage -FA E: C:\Temp D:\Recovered -x
```
- -FA performs a deeper full scan and then copies recoverable files.
- This can take much longer than -QA.
If more control is needed, use manual mode.
- Diagnose mountability:
```
     refsutil salvage -D E: C:\Temp
```
- Quick scan only:
```
     refsutil salvage -QS E: C:\Temp -v
```
  This logs discovered files in foundfiles.<volume signature>.txt in the working directory.
- Copy specific files from the generated file list:
```
     refsutil salvage -SL E: C:\Temp D:\Recovered FileList.txt -x
```
For Hyper-V recovery, validate the recovered VM files.
- Check whether recovered VHD, AVHDX, and configuration files are present.
- If files are missing or irrecoverable, restore from the latest backup.

Important cautions:

Do not place the working directory or target directory on the damaged source volume.
The -m and -sv options can lead to unexpected results.
-x is disruptive because it forces a dismount and invalidates open handles.
If the storage path is unstable or the storage pool is degraded, validate storage connectivity, drivers, and firmware before or during recovery.

References:

Answer 2

Hello Samuel,

Event ID 133 on ReFS volumes indicates metadata corruption that the file system cannot self-heal. At this point, the only supported method to attempt recovery is using refsutil.exe, which is Microsoft’s internal salvage utility for ReFS. The salvage process does not repair the volume in place; instead, it extracts intact files and directories into a new location.

The correct procedure is to run refsutil salvage against the affected volume, targeting an alternate output path. For example, if your degraded ReFS volume is mounted as E:, you would execute from an elevated command prompt:

refsutil salvage E:\ D:\RecoveredVMs

The first parameter is the source ReFS volume, the second is the destination path on a healthy NTFS or ReFS volume where recovered data will be written. The tool will walk the directory tree, skip corrupted metadata allocations, and copy out uncorrupted files. Salvage is read-only against the source, so it will not worsen the corruption.

Be aware that salvaged VM images may be incomplete if their metadata or stream allocations were damaged. You should validate each .vhdx or .avhdx file after recovery. In practice, Hyper-V checkpoints are particularly vulnerable, so expect to lose some chain integrity. If the salvage output contains partial files, you may need to discard those backups and rely on earlier intact restore points.

Microsoft’s official guidance is clear: refsutil is not a repair tool, it is strictly for data extraction. Once salvage is complete, the corrupted ReFS volume should be reformatted before reuse. Continuing to operate on a degraded ReFS volume risks further corruption.

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. Should you have more questions, feel free to leave a message. Have a nice day!

HP.