ERROR_INVALID_BLOCK 0x00000009: Hard Drive Fix Guide

You try to copy a file, format a drive, or boot Windows and instead get slapped with ERROR_INVALID_BLOCK (0x00000009) — the storage control block address is invalid.

Annoying, but usually fixable. The culprit here is almost always a corrupted volume bitmap, a flaky SATA connection, or a MBR that got scrambled by an unclean shutdown. Let's run through the fix in order of what actually works.

Fix 1: Run CHKDSK with the right flags

Don't just run chkdsk C: with no switches — that won't repair anything, it only reports. You want the repair flags. Open an elevated Command Prompt (right-click, Run as administrator) and run:

chkdsk D: /f /r /x

Swap D: for whichever drive is throwing the error. What those flags do:

/f — fixes errors on the disk
/r — locates bad sectors and recovers readable info
/x — forces the volume to dismount first (needed if anything has a file handle open)

If it's your system drive (C:), CHKDSK will ask to schedule at next reboot. Say yes, then reboot and let it run. A 1 TB drive can take 45 minutes to 3 hours with /r. Grab coffee. Don't interrupt it.

Fix 2: Rebuild the volume with diskpart

If CHKDSK throws more errors or the drive won't mount at all, the partition table itself is probably toast. Diskpart can rebuild it — but understand this wipes the drive. If the data matters, clone first.

diskpart
list disk
select disk 2
clean
create partition primary
format fs=ntfs quick
assign letter=E
exit

Pick the right disk number. If you've got a 500 GB Samsung 870 in slot 2 and a 4 TB WD Black in slot 3, and you clean the wrong one, you'll know immediately. That's why I tell people to disconnect every drive except the problem one before running diskpart.

Fix 3: Reseat the SATA data and power cables

Yeah, it sounds like a joke. It isn't. ERROR_INVALID_BLOCK has shown up on dozens of machines where the SATA cable was crimped, cheap, or had a loose connector. Windows writes a block, the drive reports it back with a garbage address, boom — 0x00000009.

This is especially common on 3.5" drives in tower cases where the drive cage puts pressure on the cable. Swap the SATA data cable for a known-good one. If the drive is external USB, plug it directly into a rear USB port — not the front panel, not a hub, not a dock. Front USB ports on cheap cases deliver under-spec voltage and that alone can trigger this.

Why any of this works

The error code 0x00000009 means the OS handed a block address to the storage stack and the driver couldn't match it to a valid entry in the volume's allocation structure. Three things cause that:

NTFS metadata got corrupted — the $Bitmap, MFT, or boot sector no longer agrees with what's physically on disk. CHKDSK rebuilds those structures from redundant copies (NTFS keeps a backup of the boot sector at the end of the volume).
Physical I/O is failing — the drive returns bad data, so the address it reports doesn't line up. Cable swaps and USB port changes fix this.
The partition table is unreadable — nothing knows where the volume starts, so every block address is invalid. Diskpart wipes and recreates.

Match the symptom to the fix. Drive mounts but throws errors on read/write → CHKDSK. Drive missing from Explorer entirely → diskpart. Errors only on a specific port or dock → cable.

Less common variations

Error on a USB flash drive

Fake-capacity drives from AliExpress report 128 GB but only have 8 GB of real NAND. When you write past the real capacity, addresses become invalid and you get 0x00000009. Test with H2testw before trusting any flash drive you didn't buy from a real retailer.

Error during Windows install

Usually a bad ISO or a failing DVD. Rebuild the USB installer with Rufus and use a fresh ISO from Microsoft's site. If it's a new NVMe drive, check the BIOS — some boards need CSM disabled and the drive initialized as GPT.

VMware or Hyper-V virtual disks

VMDK and VHDX files that were force-killed mid-write get corrupted at the block level. Run vmkfstools -V on ESXi, or use Mount-VHD -ReadOnly then Repair-VHD in PowerShell on Hyper-V.

RAID arrays

If this fires on a hardware RAID volume, don't touch diskpart. Pull the controller logs first. A degraded array masquerading as a healthy one will eat your data if you rebuild the wrong way.

Prevention

Always eject USB drives properly. Pulling them mid-write is the #1 cause of NTFS bitmap corruption.
Use a UPS. Unclean shutdowns kill boot sectors.
Run chkdsk /scan monthly on data drives — it's fast and catches bitmap drift early.
Replace SATA cables older than five years, especially the flat red ones that ship free with motherboards. They're garbage.
Check SMART status with CrystalDiskInfo. Reallocated sector count going up = drive is dying, back up now.

If you've done all of the above and the error persists on the same drive, the drive itself is failing. Replace it. Don't keep poking a dying disk hoping CHKDSK will save it — it won't.