How to Fix “The Device Is Not Ready” Error 0x80070015 When BitLocker Encryption Resumes

Had a BitLocker encryption job stall out at 10% on an external drive after a bad shutdown, and every attempt to resume it just threw “Encryption could not be resumed. The device is not ready.” with error code 0x80070015. This one’s genuinely stressful when it happens, mostly because your data is sitting half-encrypted in the meantime and the instinct is to panic-click things. Don’t — here’s what actually works.

Quick Answer

• Error 0x80070015 during BitLocker resume almost always points to a file system or disk-level problem, not BitLocker itself
• Run chkdsk /f on the affected drive first — this fixes the majority of documented cases
• Don’t force-disconnect or reformat the drive before trying chkdsk, since that risks the partially encrypted data
• If chkdsk reports RAW file system, the fix path changes entirely — that’s a more serious disk issue, not a simple resume failure
• manage-bde -resume from an elevated command prompt is the direct way to retry once the underlying disk issue is fixed

Why It Fails

BitLocker’s resume operation needs a clean, consistent file system to pick back up from where it left off. Error 0x80070015 is Windows’ generic “device not ready” code, and when it shows up specifically during a BitLocker resume, it means the encryption driver tried to read or write to the volume and got rejected at a lower level — the disk itself, not BitLocker’s own logic.

A few specific things cause this in practice:

1. An interrupted encryption or decryption process from an unclean shutdown. This is the single most common trigger — a power loss, forced restart, or accidental disconnection mid-encryption leaves the drive’s file system in an inconsistent state that BitLocker won’t resume into.
2. Corrupted file system attribute records. Running chkdsk on affected drives frequently turns up corrupt attribute records even when the drive otherwise seems to mount and read fine — this is a real, documented pattern reported across multiple cases.
3. A drive that dropped to RAW file system. If chkdsk reports the file system as RAW instead of NTFS, that’s a more serious state — the file system table itself is unreadable, and chkdsk won’t even run on it in that condition, which means BitLocker definitely won’t resume either.
4. Connection instability on external drives. For USB and external drives specifically, an unstable connection — a failing cable, a port with power delivery issues, or a drive that’s spinning down unexpectedly — can trigger this exact error during resume even when the file system itself isn’t corrupted.
5. Hardware-level disk problems. In less common but real cases, this points to actual physical drive degradation rather than anything fixable through software — worth keeping in mind if chkdsk and the other fixes below don’t resolve it.

Technical Comparison

Step-by-Step Fixes

Step 1: Don’t Panic-Disconnect the Drive

Before doing anything else — leave the drive connected and don’t force-eject it, reformat it, or run anything destructive. A partially encrypted drive with a paused state is recoverable in most cases; a partially encrypted drive that got forcibly disconnected mid-operation is a much worse starting point.

Step 2: Run CHKDSK With the Fix Flag

Open Command Prompt as Administrator:

chkdsk X: /f

Replace X: with the actual drive letter. You’ll likely get a prompt about the volume being in use — since BitLocker has it locked, you may need to force a dismount:

chkdsk X: /f /x

Confirm the dismount warning if prompted. This is the single fix that resolves the most documented cases of this exact error.

Step 3: Check the File System Type Before Proceeding Further

If chkdsk comes back reporting the file system as RAW rather than NTFS, stop here and don’t run /f repeatedly hoping it’ll fix itself — RAW means chkdsk fundamentally can’t operate on the volume’s file table. This needs data recovery tooling before you attempt anything BitLocker-related again, since forcing further BitLocker operations against a RAW volume risks the data that’s already there.

Step 4: Retry the Resume Command

Once chkdsk completes cleanly:

manage-bde -resume X:

If this succeeds, encryption will pick back up from its last checkpoint rather than starting over — no need to worry about it decrypting and re-encrypting from scratch.

Step 5: Check the Physical Connection (External Drives)

If this is a USB or external drive and chkdsk came back clean but the resume still fails:

1. Try a different USB cable, ideally one you know is solid
2. Try a different port — direct-to-motherboard ports tend to be more stable than a hub or a front-panel port on older machines
3. Check if the drive has its own external power supply that might be dropping out
4. Retry the resume command after switching connections

Step 6: Check Event Viewer for the Underlying Cause

Open Event Viewer → Windows Logs → System, and filter for errors around the time you attempted the resume. BitLocker-related and disk-related errors here often point more specifically at what’s actually failing than the generic 0x80070015 code does on its own.

What Actually Worked For Me

My case was the interrupted-shutdown scenario — laptop battery died mid-encryption on an external drive I was backing up to, dumb mistake on my part for not checking the charge level first. Tried manage-bde -resume immediately after reconnecting and got the exact 0x80070015 error.

First instinct honestly was to just unplug and replug the drive a few times, which did nothing, as I probably should’ve expected. So I ran chkdsk without the fix flag first just to see what it’d report, and it came back listing a handful of corrupt attribute records — not RAW, thankfully, just genuinely corrupted metadata from the abrupt interruption.

Ran chkdsk X: /f /x, confirmed the forced dismount, and let it run — took a few minutes on a drive that size. After it finished, manage-bde -resume went through without complaint and the encryption picked up right where it left off. The whole thing was maybe fifteen minutes of actual work once I stopped second-guessing whether chkdsk was safe to run on a partially-encrypted BitLocker volume. It is, for the record, at least in this kind of scenario — I’d been mildly worried it would make things worse.

Advanced Fixes and Edge Cases

When manage-bde itself throws a different error after chkdsk. If resume still fails after a clean chkdsk pass, check the specific error code returned — a different code than 0x80070015 at that point usually means you’re dealing with a second, separate issue rather than the same one persisting.

BitLocker Repair Tool for severely damaged volumes. Windows includes repair-bde, a dedicated recovery tool for BitLocker volumes that won’t mount normally. It requires a second, unencrypted drive with enough free space to hold the recovered data, since it works by extracting recoverable sectors to a new location rather than repairing in place. Worth knowing this exists before assuming a badly corrupted BitLocker drive is a total loss.

Suspend before attempting risky fixes. If you need to run further diagnostics and want to reduce risk to the encryption state, manage-bde -pause X: puts the operation into an explicitly suspended state rather than leaving it in the ambiguous “could not resume” limbo — not always necessary, but worth doing if you’re going to be poking at the drive for a while.

Testing with a completely different USB controller. On some machines, USB 3.0/3.1 ports have caused intermittent BitLocker resume failures on certain external enclosures — worth trying a USB 2.0 port as a diagnostic step if you’ve got one, purely to rule out a controller-level compatibility quirk before assuming it’s file system corruption.

What Rarely Works

Repeatedly clicking Resume in the GUI without addressing the underlying disk issue almost never works — the error is going to keep firing until whatever chkdsk would’ve caught gets fixed, so mashing the resume button just wastes time. Similarly, disabling and immediately re-enabling BitLocker on a drive that’s already showing this error is risky — a few documented cases show this making an already-inconsistent volume worse rather than better, since you’re asking the encryption driver to start a fresh operation on a file system that’s already struggling.

Prevention Tips

• Don’t disconnect external drives or let laptops lose power mid-encryption — check battery level and connection stability before starting a BitLocker job on anything you can’t leave plugged in and undisturbed
• Run a quick chkdsk on drives before starting BitLocker encryption in the first place, especially on older external drives
• Keep BitLocker recovery keys backed up somewhere separate from the encrypted drive itself, so a worse-case scenario doesn’t leave you locked out entirely
• For large drives, consider starting encryption when you know you won’t need to move or disconnect the machine for a while

FAQ

Will chkdsk /f delete my partially encrypted data? No, chkdsk repairs file system structure — it doesn’t touch the BitLocker encryption state or delete files, though as with any disk repair tool there’s inherent risk if the drive has deeper problems.

Can I just cancel BitLocker entirely instead of fixing this? There’s no clean “cancel” mid-encryption. You can pause and eventually decrypt, but the drive needs to be in a readable state for that too, so a lot of this troubleshooting applies either way.

Is my data lost if chkdsk reports the drive as RAW? Not necessarily, but it needs a different approach — data recovery tools built for this scenario rather than a standard chkdsk repair. Don’t run repeated write operations against a RAW volume hoping to fix it, since that risks making recovery harder.

Does this affect internal drives the same way as external ones? The underlying cause — file system inconsistency from an interruption — is the same, though internal drives are less prone to the connection-instability version of this problem specifically.

Editor’s Opinion

the panic factor on this one is real because your data feels stuck in encryption limbo, but in most cases its just a chkdsk away from fixed. dont go disconnecting and reconnecting the drive a bunch of times hoping that helps, it doesnt, just run chkdsk /f and see what it actually reports before doing anything more drastic

A note on data safety: back up what you can before running disk repair commands if there’s any way to do so, especially if chkdsk reports the file system as RAW.