Windows 11 Home 搭載 PC に SQL Server 2017/2019/2022（Developer／Evaluation／Express／Standard 等）を入れようとしたら “Database Engine Services failed（-2061893606）” で止まる――そんな相談が増えています。本記事では原因の本質（NVMe のセクタ報告値と SQL Server の仕様不一致）を、再現するログの読み方から確実な回避策、検証・復旧まで具体的に解説します。まずは手順①～③を順に実行してください。
Windows 11 Home に SQL Server をインストールできない問題の全体像
Windows 11 Home 環境で SQL Server セットアップが完了したように見えても、再起動後に SQL Server サービス（Database Engine）が起動しない、あるいはセットアップ中に “Database Engine Services failed”（エラー コード -2061893606）で失敗する事象があります。対象は 2017／2019／2022 の主要エディション（Developer／Evaluation／Express／Standard など）に及びます。
この現象のコア原因は、「一部の NVMe SSD が Windows 11 で 4 KB を超える物理セクタ サイズ（例：32 KB）を OS に報告する」こと、そして「SQL Server が 512 バイトまたは 4 KB までしかサポートしない」という仕様にあります。結果として初期起動時に master／model／msdb などシステム データベースのファイルを開けず、サービスが停止します。
エラーログの特徴と見分け方
セットアップ画面では下記のように報告されることが多く、内部ログでは共通の兆候が見られます。
- Component error code:
0x851A001A - エンジン起動直後の ERRORLOG に、セクタサイズ不一致に類するメッセージが記録される（例）
FCB::Open failed: Could not open file 'C:\Program Files\Microsoft SQL Server\...\model.mdf' for file number 1.
The operating system returned error 22 (not same sector size / The device does not recognize the command).
The file '...\model.mdf' size is not a multiple of the sector size (32768).
SQL Server is terminating because of a system shutdown. This is an informational message only.ERRORLOG の既定保存先は（例）：
C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\Log\ERRORLOGSQL Server Configuration Manager > SQL Server サービス のプロパティ（起動パラメータ）で -e のパスからも確認できます。
なぜ Windows 11 Home で起こるのか（技術的背景）
近年の NVMe SSD には、物理セクタ サイズを 4 KB より大きく報告するモデルが存在します。Windows 11 はストレージ スタックの改良により、その値をより厳密に上位へ伝えるケースがあり、結果として SQL Server が許容しない値（> 4 KB）がアプリ層まで露出する場面が出ます。SQL Server は I/O 整合性とパフォーマンスの前提から、データ ファイルのセクタ アライメントを 512B/4KB に限定しており、これを超える物理セクタでは システム DB の初期化すらできないため起動時に停止します。
このギャップは「Windows 11 のバグ」や「SQL Server の単純な不具合」というより、ハードウェアの報告値とデータベース製品の仕様制限の衝突として捉えるのが適切です。
まず確認：現在のセクタ サイズを調べる
回避策に入る前に、該当 PC の論理／物理セクタ サイズを確認します。管理者のコマンド プロンプトまたは PowerShell で次を実行します。
fsutil fsinfo sectorinfo C:または（PowerShell）
Get-PhysicalDisk | Select FriendlyName, MediaType, LogicalSectorSize, PhysicalSectorSizePhysicalSectorSize が 4096 より大きい（例：32768）場合、本記事のワークアラウンドに該当する可能性が高いです。
最も確実な回避策（ワークアラウンド）
以下の手順は、既に 「インストール失敗 → 再起動後もサービスが上がらない」 状態からの復旧を含め、多数の成功報告がある実用的な方法です。特に手順①のレジストリ設定が要点です。
| 手順 | 内容 | 補足 |
|---|---|---|
| ① レジストリ修正（最も確実） | 管理者権限の コマンド プロンプトで下記を実行し再起動。REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v ForcedPhysicalSectorSizeInBytes /t REG_MULTI_SZ /d "* 4095" /f | 4095 (= 4 KB − 1) を指定し、ストレージ ドライバーに「このディスクは 4 KB 未満」と報告させる。SATA SSD ではキー名が異なる（後述）。 |
| ② 失敗したインストールを完全削除 | 設定 > アプリ > インストール済みアプリ から SQL Server 関連をすべてアンインストール。残ったフォルダー（例 C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER）をリネーム／削除。 | 不整合な DB ファイルやサービス定義を残さないため。必要に応じて SSMS など付属ツールも再インストール。 |
| ③ PC を再起動し再インストール | インストーラーを 「管理者として実行」し、通常どおりセットアップ。途中で Microsoft Update（MU）を選択しても可。 | インスタンス名は任意（既定の既定名 MSSQLSERVER／命名インスタンスいずれも可）。 |
| ④ サービス起動を確認 | 再起動後、SQL Server Configuration Manager または サービスで SQL Server (<インスタンス名>) が「実行中」になっているか確認。SSMS で localhost に接続テスト。 | 起動しない場合は ERRORLOG を再確認し、手順①の入力ミス・再起動忘れ・インストール パス不一致を見直す。 |
| ⑤ 追加オプション（必要時） | 起動パラメータに -T1800（Trace Flag 1800）を追加して I/O 判定を緩和。NVMe ファームウェアや Intel／AMD RAID ドライバーを最新版へ更新。 | Trace Flag はレジストリ変更より効果が弱い場合あり。恒久対策ではないため、あくまで補助的に。 |
レジストリ変更のポイント（NVMe / SATA 別）
NVMe の標準ドライバーを使っている場合は stornvme の配下に設定します。SATA（AHCI）やベンダー独自ドライバーを使っている場合はキーが異なります。
| 接続／ドライバー | キー例 | 値 | 備考 |
|---|---|---|---|
| NVMe（Microsoft 標準） | HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device | ForcedPhysicalSectorSizeInBytes（REG_MULTI_SZ）* 4095 | 本記事の代表例。最優先で試す。 |
| SATA AHCI（Microsoft 標準） | HKLM\SYSTEM\CurrentControlSet\Services\storahci\Parameters\Device | 同上 | ノート PC などの内蔵 SATA SSD で該当。 |
| Intel RST / VMD 等 | HKLM\SYSTEM\CurrentControlSet\Services\iaStorAC\Parameters\Device（環境により iaStorV／iaStorAVC／iaStorVD 等） | 同上 | デバイス マネージャーのストレージ コントローラー名で使用ドライバーを確認。 |
| AMD RAID 等 | HKLM\SYSTEM\CurrentControlSet\Services\rcbottom\Parameters\Device や amdsata 等（環境依存） | 同上 | ベンダー ドライバー名ごとに Services\<サービス名>\Parameters\Device を探す。 |
レジストリを GUI で手動追加するより、コマンドで確実に入れるのが安全です。PowerShell を使うなら次も可：
New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Services\stornvme\Parameters" -Name Device -Force | Out-Null
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" `
-Name "ForcedPhysicalSectorSizeInBytes" -PropertyType MultiString -Value "* 4095" -Force設定後は必ず OS を再起動してください。再起動前後で fsutil／Get-PhysicalDisk の値が期待どおりに変化しているか確認します。
なぜ「4095」なのか
SQL Server は 4 KB を上限閾値として扱います。4 KB ちょうど（4096）を指定しても改善しない構成があるため、「4 KB 未満」であることをドライバーに明示する目的で 4095 を使います。端数の 1 バイトは「4 KB を超えない」ことを保証するためのワークアラウンドです。
インストールのやり直し（クリーンアップ & 再セットアップ）
アンインストールのコツ
- 設定 > アプリから「Microsoft SQL Server 20xx」や各種コンポーネント（Database Engine Services、SQL Server Browser、Connectivity、SSMS 等）を順に削除。
- 残留フォルダーはすべてリネーム／削除：
C:\Program Files\Microsoft SQL Server\C:\Program Files (x86)\Microsoft SQL Server\C:\ProgramData\Microsoft\SQL Server\（隠しフォルダー） - サービスが残っている場合は、アンインストーラーで消せなければ最終手段としてコマンドを使用：
sc delete MSSQLSERVER（既定インスタンスの場合の例）
再インストールの実施
- インストーラーを右クリックし 「管理者として実行」。
- セットアップ時に Database Engine Services を選択。データ ディレクトリは既定のままで可。
- 完了後に OS を再起動。サービスが「実行中」になることを確認。
動作確認と検証チェックリスト
| 観点 | 確認内容 | コマンド／操作 |
|---|---|---|
| セクタ サイズ | 4096 以下（期待：4 KB 未満を報告） | fsutil fsinfo sectorinfo C: |
| サービス状態 | SQL Server (<インスタンス名>) が「実行中」 | services.msc または SQL Server Configuration Manager |
| 接続性 | SSMS から localhost へ接続成功（sa または Windows 認証） | SSMS（バージョンは新しめが望ましい） |
| ERRORLOG | セクタ関連のエラーが消え、通常の起動ログのみ | 起動パラメータ -e のパスから確認 |
FAQ：よくある誤解と注意点
これは Windows 11 Home 固有の問題？ Home 構成の個人用 PC で相談が多いだけで、ドライブが 4 KB 超を報告すればエディションに関係なく発生し得ます。Pro／Enterprise でも同様の報告があります。
<dt>SQL Server のバージョン依存？</dt>
<dd>2017／2019／2022 の幅広いビルドで再現します。累積更新で改善する可能性はありますが、<strong>現時点での決定打はレジストリ ワークアラウンド</strong>です。</dd>
<dt>なぜトレース フラグ（<code>-T1800</code>）だけでは直らないことがある？</dt>
<dd>トレース フラグは I/O 判定の一部ロジックを緩和しますが、<strong>物理セクタ報告値そのものが上限超過</strong>だと根本の整合性チェックを通過できない構成があるためです。</dd>
<dt>レジストリ変更の影響は？</dt>
<dd>ストレージ ドライバーが OS に報告する物理セクタ サイズを上書きするため、<strong>対象デバイス上の他アプリにも影響</strong>します。業務システムやバックアップ製品など、I/O に厳しいアプリが同居する場合は事前検証を推奨します。</dd>
<dt>4096 を指定してはいけないの？</dt>
<dd>4096（ぴったり 4 KB）で動いた事例もありますが、<strong>4095 の方が広い構成で確実</strong>という報告が多いため、本記事では 4095 を推奨しています。</dd>トラブルシューティング深掘り
セットアップ時に止まる／ロールバックする
- 先にレジストリ ワークアラウンド（手順①）を適用 → 再起動 → クリーンアップ（手順②）→ 再インストール（手順③）。
- ウイルス対策やバックアップ エージェントがファイルをロックしていないか確認。
サービスが「開始」→「停止」を繰り返す
ERRORLOGを確認。セクタ不一致以外に、パス権限やアンチウイルス除外漏れ（sqlservr.exe, データ／ログ フォルダ）を疑う。- 起動パラメータから
-m（シングルユーザー）を付けて起動し、masterの整合性をチェックする方法もあるが、セクタ問題が残っている場合は起動しない。
ベンダー ドライバー環境でキーが分からない
- デバイス マネージャー > 記憶域コントローラー > 対象デバイスのプロパティ > ドライバーの詳細で .sys 名を確認。
- レジストリの
HKLM\SYSTEM\CurrentControlSet\Servicesの配下から、同名（または近い名称）のサービス キーを探す。 Parameters\Deviceを作り、同じ Multi_SZ 値を設定。
安全なロールバック（元に戻す）
将来の Windows／SQL Server の更新で正式対応が入った場合、ワークアラウンドを解除して元の報告値に戻したいことがあります。以下の手順で復元できます。
- 管理者コマンド プロンプトで次を実行：
REG DELETE "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" /v ForcedPhysicalSectorSizeInBytes /f- OS を再起動。
fsutil／Get-PhysicalDiskで物理セクタ サイズが元に戻ったことを確認。
万一トラブルが発生しても復旧できるよう、レジストリの エクスポート（.reg バックアップ）を事前に取っておくと安心です。
恒久対処の選択肢（運用設計の観点）
- データ／ログを 4 KB 物理セクタの別ドライブに置く：SATA SSD や別ベンダー NVMe へ移設。
- Linux 版 SQL Server へ移行：Docker を含む選択肢。Windows ストレージ スタックの影響を避けられる構成もある。
- Windows 10 にダウングレード：ハードウェアとドライバーの相性で改善するケースあり。
- ベンダー製ファームウェア／ドライバーの更新：物理セクタ報告値や互換性が改善される場合がある。
ただし、いずれも「検証してから本番適用」が大前提です。OS や SQL Server の累積更新で根本的に解消される可能性もあるため、定期的に最新情報を確認し、ワークアラウンドの継続要否を見直してください。
実行例と確認コマンド集（コピー用）
NVMe（stornvme）の場合：適用
:: 管理者コマンド プロンプトで
REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" ^
/v ForcedPhysicalSectorSizeInBytes /t REG_MULTI_SZ /d "* 4095" /f
shutdown /r /t 0 :: 再起動
fsutil fsinfo sectorinfo C:
Get-PhysicalDisk | Select FriendlyName,LogicalSectorSize,PhysicalSectorSize復元（削除）
REG DELETE "HKLM\SYSTEM\CurrentControlSet\Services\stornvme\Parameters\Device" ^
/v ForcedPhysicalSectorSizeInBytes /f
shutdown /r /t 0SQL Server 再インストール後のチェック
:: サービス状態
sc query type= service state= all | findstr /I "SQL Server"
:: ERRORLOG の場所（パラメータ -e）
SQLServerManager.exe を開き、該当インスタンスのプロパティ -> 起動パラメータで確認リスクとベストプラクティス
- 影響範囲を理解する：レジストリ変更は 対象デバイス全体の物理セクタ報告値を上書きします。バックアップ、暗号化（BitLocker）、仮想化（Hyper-V／VMWare）、高スループットのログ収集など、I/O 集約アプリが同居していないかを確認し、念のためテスト環境で検証してください。
- ロールバック計画：.reg のエクスポート、復元手順、バックアップの整備。
- ログで裏取り：ERRORLOG の該当部分を読み、セクタ不一致が消えていることを最終確認。
- 更新の継続：SQL Server の CU、Windows Update、ストレージ ドライバー／ファームウェアの最新化を継続。
まとめ：既知の制限 × ワークアラウンドで確実に回復
本件は、Windows 11 で一部 NVMe が 4 KB 超の物理セクタを報告することと、SQL Server 側の 512B／4KB 制限がぶつかった結果です。再発防止と早期復旧を両立するうえで、① レジストリで 4095 を設定 → ② 失敗インストールをクリーンに削除 → ③ 再インストール の三段構えが最も確実です。状況によっては -T1800 の併用やドライバー更新も検討してください。どうしても解決しない場合は、4 KB 物理セクタの別ドライブ運用、Windows 10 への切り戻し、あるいは Linux 版 SQL Server へ移行する選択肢も現実的です。
上記の手順で、「インストール失敗 → 再起動後もサービスが上がらない」という状態からの復旧は 実運用で複数の成功報告があります。まずは本稿の ①～③ を順番に実施し、ログで裏取りしながら進めてください。
付録：関連チェックポイント早見表
| 項目 | 要点 | 確認／操作 |
|---|---|---|
| OS エディション | Home に限らず発生し得る | 設定 > システム > バージョン情報 |
| SQL Server バージョン | 2017／2019／2022 で再現 | セットアップ メディアのビルド、CU 適用状況 |
| 物理セクタ | 4096 超は不適合 | fsutil／Get-PhysicalDisk |
| ドライバー | stornvme／storahci／iaStor** など | デバイス マネージャーで確認、該当サービス配下にキー追加 |
| ERRORLOG | error 22、sector size、FCB::Open など | 既定ログパスまたは -e で確認 |
| Trace Flag | -T1800 は補助的 | 構成マネージャー > 起動パラメータに追加 |
参考メモ（オフライン参照用）
- Microsoft のサポート資料には「OS が 4 KB を超えるディスク セクタ サイズを報告する場合の対処」が整理されています。
fsutil fsinfo sectorinfoで現在のセクタ サイズ、Get-PhysicalDiskでデバイスごとの論理／物理値が確認できます。
なお、本記事では外部リンクを掲載していません。社内ナレッジや検証環境で必ず裏取りのうえ、本番環境に適用してください。
コメント