Windows reaches kernel startup but cannot mount the volume containing Windows and stops with UNMOUNTABLE_BOOT_VOLUME. The immediate mechanism is a failed boot-volume mount; possible causes include logical file-system damage, interrupted servicing, a failing storage path, or less commonly a separate controller/driver problem.

Search UNMOUNTABLE_BOOT_VOLUME 0xED together with the storage model, any CHKDSK result, and the preceding update or power-loss event. Do not search only blue screen hard drive; it merges file-system, storage-driver, controller, and hardware mechanisms.

Use this procedure when the disk is consistently detected, the Windows partition exists, and Windows reports 0xED or file-system evidence consistent with a failed mount.

Do not use it when the drive disappears from firmware, changes identity or size, emits repeated I/O errors, or fails vendor diagnostics. Do not use it for 0x7B immediately after a controller-mode change; restore the original controller mode or required driver instead.

The exact Windows build may remain unknown for volume inspection, CHKDSK, and offline SFC. The physical disk, Windows volume, file-system state, and whether the drive remains stable must be known.

Before you start:

  • Windows Recovery Environment or installation media
  • Command Prompt
  • Consistently detected storage device
  • A backup or image before heavy recovery when data matters or hardware failure is suspected

Open Repair your computer > Troubleshoot > Advanced options > Command Prompt. Do not begin with BCD rebuilding; first establish whether the Windows file system can be mounted and read.

  • Do not run chkdsk /r repeatedly on a drive suspected of physical failure.
  • Do not treat CHKDSK repairs as proof that the hardware is healthy.
  • Do not run bootrec /fixmbr, /fixboot, and /rebuildbcd merely because Windows cannot mount its volume.
  • Do not initialize, format, or convert the disk.
  • Do not change SATA/AHCI/controller mode without recording and restoring the original value.
  • Do not continue writing to a drive that disappears or reports escalating errors.

Stop when the drive is unstable, errors recur after repair, the volume is already clean, or evidence points to a controller/driver rather than NTFS.

Check the cause

  1. Record the complete stop code and whether the failure followed an update, abrupt power loss, clone, controller change, or earlier disk warning.

  2. Detect and map the Windows volume:

    diskpart
list disk
list volume
select volume <Windows-volume-number>
detail volume
assign letter=W
exit

  3. Confirm that the drive's reported size and partition layout remain stable across two entries into WinRE. A changing or disappearing disk is not a logical-only file-system case.

  4. Attempt a directory read:

    dir W:\Windows
dir W:\Windows\System32\Config

  5. Run CHKDSK without repair switches first:

    chkdsk W:

  6. Record the complete summary, especially:

    • file-system type;
    • whether Windows found errors;
    • unreadable segments or I/O errors;
    • bad-cluster information;
    • whether the volume could be opened at all.

  7. If the drive repeatedly vanishes, CHKDSK cannot read it, or diagnostics report failure, stop and image/recover data before additional writes.

  8. If the volume is readable and CHKDSK reports ordinary logical errors, proceed to Branch A.

  9. If CHKDSK reports no file-system errors, treat 0xED as evidence requiring storage-driver, filter-driver, update, or hardware analysis rather than forcing a repair.

Branch A — Repair demonstrated logical file-system errors

  1. Confirm that required data is backed up and the storage device is stable.

  2. Run file-system repair:

    chkdsk W: /f

  3. Record the final summary. Do not interrupt CHKDSK while it is actively repairing metadata.

  4. Restart and test.

  5. If CHKDSK specifically reports unreadable clusters or a surface-read problem and the drive has already been imaged, a deeper scan can be considered:

    chkdsk W: /r

  6. Do not make /r the automatic first step. It performs a much heavier read and is inappropriate before imaging a drive that may be failing.

Branch B — Repair protected system files after the volume mounts

  1. Once CHKDSK completes and W:\Windows is readable, run offline SFC:

    sfc /scannow /offbootdir=W:\ /offwindir=W:\Windows

  2. Record the final SFC result.

  3. Restart and test.

  4. If SFC requires a matching source, use FIX-066 rather than copying files manually.

Branch C — Roll back a directly preceding Windows update

Use this branch when the volume is now clean/readable and the first 0xED occurred during or immediately after servicing.

  1. Return to Advanced options > Uninstall Updates.
  2. Select Uninstall latest quality update for a monthly update or Uninstall latest feature update for a version upgrade when available.
  3. Complete the rollback and restart.
  4. Preserve Update History and servicing logs once Windows starts.

Check the result

  • Windows completes three normal starts.

  • A read-only chkdsk W: or chkdsk C: from running Windows reports a clean file system.

  • Storage diagnostics report no hardware failure.

  • Event Viewer does not show recurring disk, NTFS, or storage-controller errors during startup.

  • The 0xED stop does not recur after a cold boot and restart.

  • CHKDSK repairs logical metadata and Windows starts: The failed mount involved file-system damage. Continue monitoring storage health.

  • The volume is clean but 0xED remains: Investigate storage drivers, filter drivers, controller settings, and hardware. Do not repeat CHKDSK.

  • The code changes to 0x7B: Use the controller/driver path; the volume may be healthy but inaccessible through the active storage stack.

  • The drive disappears or CHKDSK reports repeated I/O failures: Stop repair writes and preserve data.

  • SFC repairs files after CHKDSK: Both file-system metadata and protected files were affected; verify both after startup.

To undo the change:

CHKDSK repairs do not have a simple undo. The rollback is the pre-repair disk image or backup. Update removal can be reversed later by reinstalling the corrected update after the system is stable. SFC repairs can be reversed through System Restore or image restoration, not by copying random prior files.