An Azure VM with 8 KB Sector Size Can Break SQL Server

The Symptoms

Setup runs normally until it starts the Database Engine for the first time. Then the Database Engine Services feature fails. In Summary.txt in the setup log folder:

Feature:                Database Engine Services
Status:                 Failed
Component error code:   0x851A0019
Error description:      Could not find the Database Engine startup handle.

Depending on the version and the exact moment of failure, the error code can also be 0x851A001A ("Wait on the Database Engine recovery handle failed"). The real cause is in the SQL Server error log:

Error: 5178, Severity: 16, State: 1.
Cannot use file '...\master.mdf' because it was originally formatted with sector size 4096
and is now on a volume with sector size 8192. Move the file to a volume with a sector size
that is the same as or smaller than the original sector size.

If you try to put a database file on such a volume on an instance that is already running, you get the sibling message instead:

Error: 5179, Severity: 16, State: 1.
Cannot use file '...', because it is on a volume with sector size 8192.
SQL Server supports a maximum sector size of 4096 bytes.

The key number in all of them is 8192. The setup error codes alone are generic (they appear for many different startup failures); the error log tells you it is the sector size.

Why It Happens

SQL Server supports disks with a sector size of 512 bytes or 4 KB, nothing larger. Microsoft states explicitly that no released version of SQL Server is compatible with sector sizes above 4 KB. The setup itself ships system database files (master, model, msdb) that were created on 4 KB sectors, and SQL Server refuses to open them on a volume with larger sectors.

Newer Azure VM series are where this shows up most often. According to Microsoft:

v6 VM series with an NVMe-only storage interface, such as Dadsv6, Eadsv6, Easv6 and Fasv6, expose their local NVMe disks with a default native sector size of 8 KB.
Premium SSD v2 and Ultra Disk can be affected when the disk is created with a 4096-byte logical sector size but presented through a host that reports an 8 KB physical sector size.
Standard HDD, Standard SSD and Premium SSD (v1) data disks attached to earlier VM series typically present 4 KB and are not affected.

It is not purely an Azure problem. With Windows 11, Microsoft changed the native NVMe driver to report the sector size the device actually announces, instead of the emulated 4 KB that older drivers passed on. The same NVMe SSD that showed 4 KB under Windows 10 can show 8 KB or 16 KB under Windows 11. That is why some on-premises machines, laptops with LocalDB included, hit the same errors after an OS upgrade, sometimes together with "There have been 256 misaligned log IOs which required falling back to synchronous IO" in the error log.

Marketplace images are not affected. SQL Server VM images from Azure Marketplace are preconfigured for a 4 KB sector size. The problem hits you when you deploy a plain Windows VM and install SQL Server yourself, which is exactly what many teams do for licensing, standardization or custom setup reasons. Microsoft's Azure SQL VM checklist lists "storage with 8-KB sector size" as an unsupported configuration for manual installations.

How to Check Before You Install

From an elevated prompt, for every volume that will hold SQL Server files (including C: if the system databases go there during setup):

fsutil fsinfo sectorinfo E:

Look at two lines:

PhysicalBytesPerSectorForAtomicity   :  8192
PhysicalBytesPerSectorForPerformance :  8192

If the two values differ, the larger one counts. Anything above 4096 means SQL Server will not work on that volume as it is. A quick view of all disks in PowerShell:

Get-PhysicalDisk | Select-Object FriendlyName, BusType, LogicalSectorSize, PhysicalSectorSize

Put this check into your VM build process, before the SQL Server installation step. Finding it afterwards costs you an uninstall, a reboot and a reinstall.

The Fix: Force a 4 KB Sector Size

Microsoft's documented solution is a Windows registry value for the NVMe driver (stornvme) that makes Windows report a 4 KB sector size to the file system:

If SQL Server setup already ran and failed, uninstall the failed instance first.

Add the registry value (elevated PowerShell):

New-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device' `
                 -Name 'ForcedPhysicalSectorSizeInBytes' -PropertyType MultiString `
                 -Value '* 4095' -Force

or with reg.exe:

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v "ForcedPhysicalSectorSizeInBytes" /t REG_MULTI_SZ /d "* 4095" /f

Restart the VM. The setting only takes effect after a reboot.
Verify with fsutil fsinfo sectorinfo E:: the physical sector values should now show 4096.
Install SQL Server.

The value is * 4095, not * 4096. That is how Microsoft documents it; do not "correct" it. The * applies it to all NVMe devices. It is a multi-string value (REG_MULTI_SZ), not a DWORD.

Things to know about this setting:

It is OS-wide. Every NVMe drive that is attached now, and every drive attached later, is reported with 4 KB sectors until you remove the value. That is usually what you want on a SQL Server VM, but it belongs in your build documentation so nobody is surprised later.
No trace flag needed. Trace flag 1800 is for mixed 512-byte/4 KB log disks between replicas, not for this problem. Microsoft states it is not required here.
Storage pools must be rebuilt. If you already created a Storage Spaces pool on the 8 KB disks for SQL Server files, remove the pool, apply the registry value, reboot, and create the pool again before installing SQL Server.
Back up the registry (or snapshot the VM) before the change, as with any registry edit.

Alternatives

Choose a different VM series whose disks present 4 KB, if the v6 features are not essential for this workload.
Deploy from an Azure Marketplace SQL Server image, which is preconfigured for 4 KB.
Use other volumes for database files. If at least the installation volume reports a supported sector size, you can install there and place user databases only on volumes that also report 512 bytes or 4 KB. In practice, with NVMe-only VM series, this rarely works out, and the registry value is the cleaner fix.

Don't Forget the Replicas

If the VM is going to be part of an Availability Group or a log shipping setup, check the sector size on every replica, not just the first one. After the fix, all replicas should report the same sector size for their log volumes; mixed 512-byte and 4 KB log disks between primary and secondary slow down synchronization (see SQL Server and Block Size for the details). Microsoft's Azure checklist recommends validating the sector size of the disks before deploying any high availability solution.

The Bottom Line

SQL Server runs on 512-byte and 4 KB sectors only. Current Azure v6 VM series with NVMe-only storage, and some Premium SSD v2 and Ultra Disk configurations, report 8 KB, and a manual SQL Server installation on them fails with error 5178 and setup code 0x851A0019. Check with fsutil fsinfo sectorinfo before you install. If the value is above 4096, set ForcedPhysicalSectorSizeInBytes to * 4095 under the stornvme driver key, reboot, verify, and then install. Make it part of your VM build so the next server never gets that far.