I know that red error box is infuriating, especially when BitLocker decides to throw a tantrum right when you need encryption on. Let's fix it.
The Real Fix for 0x80310026
BitLocker is refusing to encrypt because your drive reports a sector size it can't work with. The algorithm you picked (usually XTS-AES 128-bit or 256-bit) needs 512-byte or 4096-byte sectors that follow the classic layout. Drives exposing 4K native sectors, or odd 520/528-byte sectors from certain enterprise SSDs, will trip this every single time.
Here's what to do, in order:
- Check what your drive actually reports. Open an elevated Command Prompt and run:
fsutil fsinfo ntfsinfo C:
Look at the "Bytes Per Sector" line. Anything other than 512 or 4096 is your problem.
- Switch BitLocker to use the drive's actual sector size. This is a Group Policy change. Open
gpedit.mscand navigate to:
Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives
Enable "Choose drive encryption method and cipher strength", then set it to XTS-AES 128-bit instead of 256-bit. On some drives, 256-bit XTS is exactly what's triggering the sector mismatch. Also make sure under "Choose how BitLocker-protected operating system drives can be recovered" you're not forcing a specific encryption method from an old SOE image.
- Run the BitLocker precheck. Back at the elevated prompt:
manage-bde -on C: -used
If you still get 0x80310026, the drive itself needs addressing.
- Reformat with 512-byte logical sectors. This wipes the drive, so back up first. From diskpart:
diskpart
list disk
select disk 0
clean
create partition primary
format fs=ntfs quick unit=4096
assign
Then re-enable BitLocker. Windows will now see 512-byte logical sectors and stop complaining.
If you're on a Surface Pro 9 or a Dell OptiPlex with a Samsung PM9A1 NVMe drive, this exact error is common out of the box because those drives ship in 4Kn mode. A firmware update from Samsung or Dell sometimes flips them back to 512e — check the vendor's support page before you reformat.
Why This Actually Works
BitLocker's AES-XTS implementation (the default since Windows 10 1511) encrypts data in fixed-size blocks that align perfectly with 512-byte or 4096-byte sectors. When a drive presents 4096-byte physical sectors but emulates 512-byte logical sectors — that's "512e" — BitLocker has no problem. But when it presents 4096-byte logical sectors (4Kn), the encryption header placement collides with the drive's expected layout, and BitLocker bails out with FVE_E_FAILED_SECTOR_SIZE.
Switching to AES-CBC 128-bit (instead of XTS) can sometimes slip past the check on older hardware, but I don't recommend it. XTS gives you better protection against ciphertext manipulation, and CBC has been deprecated for BitLocker OS drives since 2016. The one exception: Windows 10 1607 and earlier builds, where CBC is the only working option on 4Kn drives. If that's your build, upgrade Windows first.
Less Common Variations
- SED (self-encrypting drive) in eDrive mode: Some Opal 2.0 SSDs expose a block size of 520 or 528 bytes when in TCG mode. BitLocker sees the non-standard sector and throws the same error. Fix: run the manufacturer's PSID revert tool (Samsung Magician, Micron Storage Executive, etc.) to reset the drive back to 512-byte sectors.
- RAID arrays with 64K stripes: Hardware RAID controllers that expose non-power-of-two stripe sizes can confuse BitLocker's sector detection. Check with
Get-PhysicalDisk | Select FriendlyName, PhysicalSectorSize, LogicalSectorSizein PowerShell. - USB enclosures: Cheap USB 3.0 bridges (the JMicron JMS578 is a repeat offender) report bogus sector sizes. Test the drive in a direct SATA/NVMe slot — if BitLocker works there, the enclosure is your problem.
- VHDX on ReFS: ReFS doesn't support BitLocker on OS drives at all, and the error message misleads. Move the VHDX to NTFS.
Preventing This Next Time
Before you deploy any new machine with BitLocker planned, run:
Get-Disk | Select Number, FriendlyName, LogicalSectorSize, PhysicalSectorSize
If LogicalSectorSize isn't 512 or 4096, stop. That drive will fight you. In enterprise rollouts, bake this check into your imaging task sequence — I've watched a 400-seat deployment fail at 5pm on a Friday because someone sourced a batch of 4Kn drives from a gray-market reseller. Add the check, or add a shorter weekend to your calendar.
And keep drives on current firmware. Manufacturers flip sector presentation between firmware revisions more often than they'd like to admit.