UNMOUNTABLE_BOOT_VOLUME: What 0x000000ED Reports

The machine stops during boot with a blue screen whose first line reads UNMOUNTABLE_BOOT_VOLUME and whose stop code is 0x000000ED. By the time that screen appears, the kernel has already loaded, enumerated the storage controller, and found a disk where the boot volume is supposed to be. What it could not do is read a file system it recognised on that volume. The distinction matters: the disk is visible, so this is not the “no boot device” family of errors, and the failure is in the layer between the raw sectors and the files that Windows needs to continue loading. Either the file system structures on the volume are damaged, or the disk is returning data the file system driver cannot use.

The check that produces this bugcheck happens early, before most drivers load and before any user-mode repair tool can run. That is why the recovery environment is the place where diagnosis and repair happen, and why advice that begins with “boot into Windows and run…” does not apply.

The two families of cause

File system damage is the more common of the two. A write was interrupted, a sector holding file system metadata was corrupted, or an update changed something the volume’s metadata depends on. The disk itself may be perfectly healthy. This family is repairable in place, and the repair is chkdsk run from the recovery environment against the correct volume.

The second family is the disk becoming unreadable. The drive may be failing mechanically or electronically, the cable or controller may be marginal, or the firmware may be presenting the disk in a mode the installed driver cannot use. This family is not repaired by chkdsk. Running repeated repairs against a failing disk stresses it and can turn a recoverable situation into an unrecoverable one.

A third case sits between them and is more common than a dead disk: the storage controller mode was changed in firmware. A machine that was installed with the controller in one mode and is now presenting the disk in another may fail to mount the boot volume even though the disk and its contents are intact. This is a settings problem, not a hardware problem, and the repair is to restore the setting rather than to touch the disk.

Confirming which family applies

The recovery environment is reached by booting the installation media and choosing Repair your computer, or by letting Windows fail to start repeatedly until it offers its own recovery options. From there, a command prompt is available.

Start with diskpart. The commands below only list information; they change nothing.

diskpart
list disk
list volume
exit

list disk shows the physical drives the recovery environment can see. list volume shows volumes with their labels, file systems, sizes, and drive letters. In the recovery environment the letters are not the ones Windows used. The volume that was C: is often D: or E: here, and the system-reserved volume may hold the letter C:. The volume to work on is identified by its label and size, not by its letter.

If the boot volume does not appear at all, or appears with a size that does not match the physical disk, the disk is not being read correctly. That points at the failing-disk or controller family. If it appears with the expected size and a recognised file system, the file system damage family is the one to pursue.

A second check is the drive’s behaviour. Clicking or grinding noises, or a disk that appears and disappears in list disk between attempts, is a reason to stop and take a copy before any repair. A drive with none of these signs can still be failing, so their absence does not rule failure out.

Repairs, least destructive first

1. Restore the controller setting if it changed

If the error appeared after a firmware change, a BIOS or UEFI update, or a change to SATA operation, restore the previous setting before touching the disk. The setting is named differently across vendors: AHCI, IDE, RAID, or Intel RST are common labels. The correct value is the one that was in place when Windows was installed. Changing it back does not modify the disk. Changing it forward to a mode Windows was not installed under can produce exactly this bugcheck.

2. Run chkdsk against the correct volume

chkdsk has two repair switches that do different things. /f fixes errors on the disk: it repairs file system metadata, rebuilds the index, and corrects inconsistencies it finds. /r does everything /f does and additionally scans every sector for bad sectors, reads data from them, and attempts recovery. /r takes much longer and puts the whole surface of the disk under read stress. On a disk that is failing, that stress is the problem: it can push a marginal drive past the point where its contents can be copied.

Run /f first, against the volume identified above. Substitute the letter that list volume showed for that volume, not the letter Windows used.

chkdsk D: /f

The output reports the file system type, whether it is dirty, and the stages it runs. A clean result reports no problems found. A repair reports the corrections it made and the amount of free space. If the volume is in use, chkdsk offers to schedule the check at the next boot; in the recovery environment the volume is not in use, so the check runs immediately.

Only if /f completes and the error persists should /r be considered, and only after confirming the disk is not failing. On a disk that is failing, take a copy of the data before any further repair.

chkdsk D: /r

The output reports each stage, including the bad-sector scan, and lists any sectors it could not read. A run that reports bad sectors is a reason to stop repairing and start copying.

3. Repair the boot records

If chkdsk completes without errors and the volume mounts, but the machine still does not boot, the boot records may be the remaining problem. bootrec operates on the system volume, not the boot volume, and its switches do different things.

bootrec /fixmbr writes a standard master boot record to the disk. On a disk using the modern GPT partitioning scheme with UEFI firmware, this switch does not apply and should not be used. On a legacy MBR disk it replaces the existing MBR code. The cost: any custom boot loader or non-Windows boot manager installed in the MBR is overwritten and will need to be reinstalled. The partition table itself is not touched, but the code that chain-loads other operating systems is gone.

bootrec /fixboot writes a new boot sector to the system partition. It does not delete files, but it replaces the existing boot sector.

bootrec /rebuildbcd scans for Windows installations and offers to add them to the boot configuration data store. It modifies the BCD store by adding the entries confirmed at its prompt.

On a legacy MBR disk the sequence is below; on a GPT disk with UEFI firmware, leave out the first line.

bootrec /fixmbr
bootrec /fixboot
bootrec /rebuildbcd

Each command reports what it did. rebuildbcd lists the installations it found and asks whether to add each one. A scan that finds no installations is a sign that the volume is still not readable, and the earlier diagnosis should be revisited rather than the commands repeated.

4. Take a copy before further repair

If the disk is failing, the priority changes from repair to preservation. The recovery environment can copy files from the volume to external media using robocopy or xcopy, provided the volume can be read at all. A failing disk may read some sectors and not others; a copy attempt that reports read errors has still preserved whatever it could read, and that is more than a repair attempt will. The same instinct to preserve rather than repair applies to digital assets, and indexcrypto.co offers guides on securing wallets and recovering from scams when a device can no longer be trusted.

robocopy D:\ E:\backup /E /R:1 /W:1

/E copies subdirectories including empty ones, /R:1 retries a failed read once rather than the default million times, and /W:1 waits one second between retries. The output lists copied files and any that failed. Files that failed to copy are the ones in damaged sectors; no repair tool will recover them from a failing disk.

What people get wrong about this error

The natural reading of UNMOUNTABLE_BOOT_VOLUME is that the disk has died. The word “unmountable” suggests the volume is beyond reach, and a machine that will not boot reinforces the impression. The mistake is understandable: the error names the volume, and the volume is on the disk, so the disk is the suspect.

What the error actually reports is narrower. The kernel found the disk and could not mount the file system on it. That is a statement about the file system layer, and the file system layer can be damaged while the disk underneath is healthy. Most instances of this bugcheck are repaired by chkdsk against the correct volume, with the disk untouched. Treating the error as certain disk failure leads to replacing hardware that was working, or to running /r repeatedly on a disk that did not need it.

The second common mistake is running chkdsk against C: in the recovery environment. The letters are reassigned there, and C: is frequently the system-reserved volume rather than the Windows volume. A chkdsk run against the wrong volume either reports no problems, because that volume is fine, or repairs the wrong file system. The volume must be identified by label and size from list volume before any repair command is issued.

The third is treating a controller-mode change as disk failure. A machine that was installed with the controller in one mode and is now presenting the disk in another will fail to mount the boot volume with this code, and the disk is intact. The change is often made in firmware while looking for an unrelated setting, or arrives with a firmware update. Restoring the previous setting costs nothing and destroys nothing, which is why it is checked before any command that writes to the disk.

After the repair

A machine that boots after chkdsk has a repaired file system, not necessarily a healthy disk. If the disk reported bad sectors, the drive should be replaced and the data migrated; a repaired file system on a failing disk will fail again. If the repair was a controller setting, the setting should be recorded so that a future firmware change does not repeat the problem. If the error appeared after an update, the update’s storage driver changes are the place to look if the error returns.