Fixed: ERROR_VOLUME_CONTAINS_SYS_FILES (0X000010F1)
Windows won't let you format or dismount a drive because it holds system files. The fix is to disable the pagefile and clear hibernation, then retry.
Yeah, this one's a pain. You're staring at Disk Management or a command prompt, and Windows just won't let you touch that drive because it thinks there are system files on it. Even if you're 100% sure there's no Windows installation there. The culprit here is almost always the pagefile or the hibernation file. Let's fix it.
Step 1: Check what's locking the volume
First, confirm the error. Run mountvol X: /L (replace X with the drive letter). If it returns something like \??\Volume{GUID}\ and the drive won't dismount, you're in the right place. Another tell: trying to format in Disk Management gives you the 0X000010F1 error.
Step 2: Kill the pagefile on that drive
This is the most common cause. Windows randomly decides your data drive is a good place for virtual memory. Here's how to fix it:
- Right-click This PC > Properties > Advanced system settings.
- Under Performance, click Settings > Advanced tab > Virtual memory > Change.
- Uncheck Automatically manage paging file size for all drives.
- Select the problematic drive in the list, set it to No paging file, click Set.
- Leave your C: drive as System managed size.
- Click OK and reboot.
After reboot, try your operation again. Nine times out of ten, that's it.
Step 3: Wipe the hibernation file (if still stuck)
Still can't touch the drive? The hibernation file (hiberfil.sys) is squatting on it. Run this from an admin command prompt:
powercfg -h off
No reboot needed for this one. Try the format/dismount again. If it works, you can re-enable hibernation later with powercfg -h on.
Why this happens
Windows is paranoid about boot-critical files. The pagefile and hibernation file are locked by the kernel the moment the OS loads. Even if the drive isn't your boot drive, Windows can place the pagefile on any available volume. The hibernation file lives on the boot drive by default, but certain configuration errors or third-party tools can scatter it.
Once you disable both, the volume has zero system file locks, and Disk Management or diskpart will let you do what you want.
Less common variations
Dump file still active
If the pagefile and hibernation are off but the error persists, check your crash dump settings. Run wmic RECOVEROS set DebugInfoType = 0 from an admin command prompt. This disables memory dumps. Reboot, then try again.
Third-party backup software
Acronis, Macrium, and others sometimes pin a VSS snapshot to a drive. Disable the scheduled backup temporarily, then force-dismount the volume with mountvol X: /P (where X is the drive letter). This offline mode bypasses software locks.
System Reserved partition spillover
Rare, but I've seen it. If the system reserved partition somehow extends onto the problem volume (thanks to a botched Windows install), you'll need to use bcdedit to reassign the boot files. That's beyond this quick fix — but if the above steps fail, that's your next rabbit hole.
Prevention for next time
- Never manually move the pagefile to a non-boot drive. It's not faster, it's just a headache.
- Before formatting a drive, run
fsutil volume dismount X:as admin. If it fails, check the pagefile first. - Keep hibernation off on desktops you don't use for instant-on. It saves a few GB of SSD space and avoids this exact lock.
That's it. Go format your drive.
Was this solution helpful?