All of Cabinet Vision's data — libraries, projects, settings, and drawings — is stored in a Microsoft SQL Server database. So if SQL isn't working properly, Cabinet Vision starts to stutter, freeze, or fail to load projects. One of the quietest and most critical causes of that is your disk's physical sector size.
What Is a Physical Sector?
Think of a disk as one giant notebook divided into small pages; each page is a sector — the smallest unit you can write to or read from. Sectors used to be 512 bytes across the board. Today, especially with SSD and NVMe drives, many manufacturers have moved to larger sectors — 4K (4096 bytes), and sometimes even more.
Why Does This Matter for SQL (and Cabinet Vision)?
SQL Server works with fixed 8KB data pages, and writes in units aligned to the sector. When the sector size doesn't match what SQL Server supports, the write can't happen atomically — and if power is lost mid-operation, part of the data may be written while the rest is lost, which can lead to database corruption.
The Exact Limit — What's Supported and What Isn't
- SQL Server supports physical sector sizes of 512 bytes and 4KB (4096 bytes) — including both 4Kn and 512e drives.
- The problem starts with disks reporting a physical sector size greater than 4KB (say, 8K or 16K) — a configuration that isn't supported by any documented version of SQL Server, and can prevent it from starting up correctly (with documented errors like 5178 and 5179), especially around the transaction log and during setup itself.
- In short: 512n, 512e, and 4Kn are all fine. What you need to avoid is a disk that reports a physical sector size above 4KB.
How to Actually Check
To actually check your disk's physical sector size on Windows, run the command in the box below as Administrator. In the output, check the PhysicalBytesPerSectorForAtomicity and PhysicalBytesPerSectorForPerformance fields — if they differ, the value that matters is the larger of the two. A value of 4096 means a 4K physical sector, which is the supported upper limit.
fsutil fsinfo sectorinfo C:Why Don't Manufacturers Mention This?
Most drive manufacturers don't list the physical sector size in their official spec sheets, and Windows' standard management tools don't always surface it clearly either. That's how users end up buying a fast new NVMe drive and only discover afterward that SQL Server — and Cabinet Vision along with it — doesn't get along with it.
It Worked on Windows 10 — Then Broke After the Windows 11 Upgrade
There's a specific version of this problem worth calling out on its own, because it's common enough that Microsoft's own troubleshooting documentation names it directly: a machine that ran Cabinet Vision and SQL Server just fine on Windows 10, then started failing to start SQL Server — with no hardware changed at all — right after the operating system was upgraded to Windows 11. The SQL Server error log on these machines typically shows entries like "There have been 256 misaligned log IOs which required falling back to synchronous IO," or an application fault in ntdll.dll during startup. In practice, the first thing most users actually see isn't a line in the SQL error log at all — it's a generic Windows error: error 1067, "the process terminated unexpectedly," when trying to start the service (whether through services.msc or with the net start command), including on named instances like the ones Cabinet Vision installs. Error 1067 is a generic message from Windows's own Service Control Manager, and on its own it explains nothing — the real cause sits in the SQL Server error log entries described above.
The cause isn't a different or worse drive — it's a change in how Windows 11 reports it. On Windows 10, the NVMe driver handed applications an emulated, "compatible" physical sector size — commonly 4096 bytes, sometimes 512 — even when the drive's own controller natively worked at something larger underneath. Windows 11's updated NVMe driver instead reports the sector size it reads directly from the device itself. Nothing about the drive changes in that upgrade; only how Windows describes it does. Run the same fsutil fsinfo sectorinfo check described above and compare: Microsoft's own documented example shows the value jumping from 4096 on Windows 10 to 16384 on Windows 11 for one identical drive, and we've seen figures as high as 65536 (64 KB) on other hardware in the field — see the confirmed case below. If the number only changed after the Windows 11 upgrade and the drive itself didn't, that's a strong sign this is a reporting change rather than a genuinely incompatible disk — and it's usually fixable.
Can It Be Changed?
The physical sector size is set at the drive's controller/firmware level, and isn't something you casually change in software. Still, for exactly this kind of reporting mismatch, Microsoft documents a real, supported fix: a registry value named ForcedPhysicalSectorSizeInBytes, added under the storage driver's own key, which forces Windows to report a 4K sector to software instead of the larger figure the driver picked up from the device. It doesn't reformat the drive, repartition it, or touch a single database file — the change lives entirely in how the driver reports itself to software, restoring the same effectively-4K behavior Windows 10 showed for that same hardware. The exact command is below. Some NVMe drives also let you reformat the namespace to a different LBA format using the manufacturer's own tooling — a destructive operation that erases all data on the drive. In other words: it's not a casual software toggle, but real, documented solutions do exist.
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v "ForcedPhysicalSectorSizeInBytes" /t REG_MULTI_SZ /d "* 4095" /fBefore touching the registry: back it up first. This exact fix targets Windows's own built-in NVMe driver (stornvme) — if the drive is running a vendor-specific NVMe driver instead, the same value has to go under that driver's own key, and Device Manager will show which driver actually owns the device. A reboot is required before the change takes effect. And if a drive was never emulating in the first place — if it's genuinely, natively formatted at a physical sector size above 4K — forcing Windows to report 4K doesn't change what the drive actually does underneath, and this fix won't help. That's a hardware limitation, not a reporting one.
Two things are worth doing before you assume the fix took. First, confirm the registry value actually wrote — the query command below reads back what's stored under the same key, so a typo in the path or the value name shows up immediately instead of after a wasted reboot. Second, once it's confirmed, reboot: the driver only picks up the new value on its next load, not while it's already running.
REG QUERY "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v "ForcedPhysicalSectorSizeInBytes"shutdown /r /t 0Once the machine is back up, don't take it on faith — run the same sector check from earlier again and confirm both values now read 4096 or lower. Only then start the SQL Server service. Cabinet Vision installs typically run on a named instance, and named instances start with the MSSQL$ prefix followed by the instance name — substitute your own installation's instance name for INSTANCENAME below.
fsutil fsinfo sectorinfo C:net start MSSQL$INSTANCENAMEA Confirmed Field Case
Here's what all of this looked like in one resolved case: a WD Green SN3000 1TB drive, reporting a Logical Sector Size of 512 bytes but a Physical Sector Size of 65536 bytes (64 KB) under Windows 11 — sixteen times SQL Server's supported ceiling. The SQL Server service for a named Cabinet Vision 2025 instance, MSSQL$CV25, refused to start, failing with the generic Windows error 1067, "the process terminated unexpectedly." The same instance, on the exact same physical machine, had run without issue under Windows 10 — nothing about the hardware had changed. After confirming the mismatch with fsutil fsinfo sectorinfo, applying the ForcedPhysicalSectorSizeInBytes registry fix described above, and rebooting, the service started cleanly and the instance came back online. This isn't a theoretical fix — it's a field-confirmed one.
A Free Diagnostic & Fix Tool
Would rather not run these checks and commands by hand? We packaged the same diagnostic and fix logic described above into a small Windows tool: a self-elevating PowerShell utility (Windows 10 and 11) with four tabs. Disks lists every drive on the machine with its logical and physical sector size, bus type, and health, flagging anything above 4096 bytes as unsupported for SQL. SQL Services lists MSSQLSERVER and every MSSQL$ named instance with its current state, start mode, and account, and can start or stop the one you select. Registry Fix shows the current ForcedPhysicalSectorSizeInBytes value, applies or removes it, and can restart Windows for you. SQL Error Logs finds the relevant ERRORLOG file and shows its tail. A colour-coded status banner sums up the verdict at a glance, and every run is logged to C:\ProgramData\SQLSectorFixTool.
Requires Administrator rights, and a Windows restart after applying (or removing) the fix. The scripts are unsigned, so Windows SmartScreen or your antivirus may flag the download or the first launch — that's expected for an unsigned PowerShell tool; if you'd rather check first, the .ps1 file is plain, readable PowerShell you can open in Notepad before running it. Like the manual fix above, the registry change targets Windows's own stornvme NVMe driver — a drive running a vendor-specific NVMe driver instead isn't covered by it. The tool only reads system information and sets or removes that one registry value; it never reformats, repartitions, or touches a database file, and it has its own "Remove compatibility fix" button if you want to undo the change. Back up the registry regardless. SHA-256 of the download: E10055385B10AAFE034D5E82D63E94CF401B0FEEF548F2721A54FB4CF36C4BE4.
How to Choose the Right Drive
- Prefer a drive that reports a physical sector size of 512e or 4Kn.
- Check the physical sector size before you buy or deploy a drive, especially with fast new NVMe drives.
- On a server running Cabinet Vision, don't assume a faster drive is automatically compatible — check it.
In Summary
Cabinet Vision runs on a sensitive, precise data system. If the disk isn't a match, the software can crash, slow down, or lose data. Before installing or upgrading a drive — stop for a moment and check its physical sector size. It's a small detail, but a critical one.
Editor's note: the original version of this post incorrectly stated that SQL Server "refuses to work with disks that have 4K sectors and above." That wasn't just a wording slip but a technical inaccuracy: SQL Server does support 4K sectors — the real problem is sectors larger than 4K. This version has been checked and corrected against Microsoft's current, official SQL Server storage documentation to present the right technical thresholds.