Windows 11 Pro で SQL Server 2022 のインストールが「Could not find the database engine startup handle」などで失敗する場合、セットアップが止まっている本当の理由は“SQL Server（データベース エンジン）サービスの起動に失敗している”ことです。本記事では、原因をログで切り分ける方法から、Windows 11 で報告の多い「256 misaligned reads」問題、手動アンインストールで壊れた環境の整理手順まで、再現性の高い流れで解説します。
起きている現象を整理する（SQLEngineDBStartConfigAction_install_configrc_Cpu64 で止まる）
SQL Server 2022 のセットアップ中に SQLEngineDBStartConfigAction_install_configrc_Cpu64 の段階で停止し、しばらくして以下のようなエラーで失敗することがあります。
- Could not find the database engine startup handle
- Wait on the Database Engine recovery handle failed
この段階は、SQL Server のファイル配置や設定を行ったあとに、SQL Server サービス（sqlservr.exe）を起動して初期化処理が正常に完了するかを確認しているフェーズです。つまり、ここで落ちるときは「セットアップの見た目」よりもサービス起動失敗の原因を追うのが近道です。
このエラーの“意味”と“よくある誤解”
「Could not find the database engine startup handle」「Wait on the Database Engine recovery handle failed」は、どちらもセットアップがデータベース エンジンの起動完了を待ったが、正常に起動できずタイムアウト/失敗したことを示す汎用メッセージです。
よくある誤解
- 「修復(Repair)を押せば直るはず」→ 直る場合もありますが、起動できない根本原因（ディスクI/O、権限、残骸、セキュリティ）があると繰り返し失敗します。
- 「インストーラーが壊れている」→ 実際にはSQL Server サービス側の問題（起動時に読み書きできない、構成が矛盾している等）が多数です。
最短ルートはログ確認：見る順番を間違えない
原因特定で最重要なのはログです。まずは“どこから見るべきか”を固定すると迷いません。
| ログ種別 | 場所（代表例） | わかること | 優先度 |
|---|---|---|---|
| セットアップログ | %ProgramFiles%\Microsoft SQL Server\160\Setup Bootstrap\Log\（SQL 2022） | どのコンポーネントで失敗したか、直前の操作、エラーコード | 高 |
| SQL Server エラーログ（ERRORLOG） | C:\Program Files\Microsoft SQL Server\MSSQL16.<インスタンス名>\MSSQL\LOG\ERRORLOG | 起動失敗の本当の理由（I/O、権限、DBファイル、設定不整合など） | 最優先 |
| Windows イベントログ | イベント ビューアー → Windowsログ → アプリケーション | サービス起動失敗の概要、アクセス拒否、依存関係の問題 | 中 |
| サービス状態 | services.msc | SQL Server サービスが存在するか、開始できるか、エラーの種類 | 中 |
ポイント：セットアップログは「失敗した場所」を教えてくれますが、「なぜ起動できないか」は ERRORLOG に書かれていることがほとんどです。
ERRORLOG の探し方（インストール途中でも作られていることが多い）
インストールが失敗しても、多くのケースで SQL Server のディレクトリは途中まで作成され、ERRORLOG が出力されています。
よくあるパス例
- 既定インスタンス（MSSQLSERVER）の例：
C:\Program Files\Microsoft SQL Server\MSSQL16.MSSQLSERVER\MSSQL\LOG\ERRORLOG - 名前付きインスタンス（例：SQLEXPRESS）の例：
C:\Program Files\Microsoft SQL Server\MSSQL16.SQLEXPRESS\MSSQL\LOG\ERRORLOG
見つからない場合のコツ
- エクスプローラーで C:\Program Files\Microsoft SQL Server\ を開き、MSSQL16. で始まるフォルダを探す
- フォルダが複数ある場合は、今回セットアップで作られた（更新日時が新しい）ものから見る
ERRORLOG はメモ帳で開けます。開いたら、末尾付近（起動直後の記録）に“起動できない理由”が出ます。
ERRORLOG でよく見るキーワードと意味
ERRORLOG は長いですが、最初は「よくあるパターン」に当てはめると早いです。
| ERRORLOG に出がちな文言（例） | 意味 | 次にやること |
|---|---|---|
| 256 misaligned reads | ディスクのセクター/アライメント周りが原因で I/O が成立せず起動に失敗する報告が多い | ディスク構成・セクターサイズ確認、配置先変更、ストレージ/ドライバー見直し |
| Access is denied / OS error 5 | フォルダ権限不足、セキュリティ機能によるブロック | データ/ログ/バックアップ先の ACL と Windows セキュリティ設定を確認 |
| FCB::Open failed | DBファイルを開けない（パス不正、権限、ロック、存在しない等） | 既存ファイル残骸、配置先の整合性、ウイルス対策の隔離/ブロックを確認 |
| Cannot create tempdb / tempdb failed | tempdb の作成先に書けない/容量不足/構成不整合 | tempdb のパス、空き容量、権限、ドライブ健全性 |
| Server TCP provider / port already in use | ポート競合で待ち状態になる（稀に起動失敗に繋がる） | 使用ポート確認、不要なSQLサービス残骸停止 |
分岐①：「256 misaligned reads」が出ている場合（Windows 11 で多い）
ERRORLOG に 「256 misaligned reads」 の記述がある場合、Windows 11 環境とストレージ構成の組み合わせで、SQL Server が想定する I/O 条件を満たせず起動の初期段階で失敗している可能性が高いです。
なぜこれで起動できなくなるのか（ざっくり理解）
- SQL Server は性能と整合性のため、ディスクに対して特殊な I/O（バッファリングしないI/Oや整列I/O）を使うことがあります。
- ところが、Windows が報告する物理セクターサイズや論理セクターサイズ、あるいは仮想ディスク/ドライバーの挙動が特殊だと、SQL Server 側で「想定通りに読めない/整列していない」と判断され、起動処理が中断されることがあります。
まず確認したい：セクターサイズと配置先
次のコマンドで、対象ディスクのセクター情報を確認します（管理者 PowerShell 推奨）。
Get-PhysicalDisk | Format-Table FriendlyName, MediaType, LogicalSectorSize, PhysicalSectorSize, Sizeまた、ファイルシステム側も確認します（例：C ドライブ）。
fsutil fsinfo ntfsinfo C:見方のポイント：LogicalSectorSize と PhysicalSectorSize が通常の組み合わせ（例：512/4096 など）でも、特定のドライバーや仮想化レイヤーで“整列して見えない”ことがあります。ここでは細かい正誤判定にこだわるより、次の「回避策」を先に試す方が早いことが多いです。
現実的に効きやすい回避策（優先順）
| 回避策 | 具体例 | 狙い | 影響 |
|---|---|---|---|
| SQL Server のデータ/ログ配置先を変更 | 問題が疑われるディスク（特定SSD/仮想ディスク/ストレージスペース等）を避け、別の物理ディスクに Data/Log を置く | I/O 条件が安定しているディスクへ逃がす | 中（移設が必要） |
| ストレージドライバー/ファームウェア更新 | NVMe ドライバー、チップセット、ストレージ関連ユーティリティを最新化 | セクター報告や整列I/Oの挙動を改善 | 中（再起動必要） |
| 仮想ディスク構成を見直す | 外付けUSBケース、暗号化/圧縮、ストレージスペース、特殊なキャッシュ機構を外して検証 | 中間レイヤーを減らし挙動を単純化 | 中〜大 |
| 一時的に別PC/別ドライブで検証 | OSやSQLを疑う前に「そのディスク構成だけが原因か」を切り分ける | 原因箇所の特定を早める | 小〜中 |
実務的なコツ：「C ドライブ（OSディスク）にデータ/ログを置く」構成は推奨されませんが、切り分け目的としては有効です。短時間だけ OS ディスクに置いて起動が通るなら、ディスク要因が濃厚になります（その後は必ず適切なドライブへ再配置してください）。
分岐②：「256 misaligned reads」がない場合に多い原因
このメッセージがない場合は、手動アンインストールの残骸や権限・セキュリティ、パス不整合が原因になっているケースが非常に多いです。ここからは頻出順に潰します。
原因A：手動削除の影響でインスタンスが中途半端に残っている
「以前は動いていた」「ファイル削除・サービス削除などを手動で行った」「複数インスタンスが混在している」場合、セットアップは次のような状態に陥りがちです。
- サービスは残っているが実体ファイルが壊れている
- 実体は残っているがレジストリ/構成情報が欠けている
- 古いインスタンスのデータディレクトリが残り、ACL が変になっている
この状態だと、セットアップがサービス作成・起動を行っても、起動直後に失敗します。
原因B：データ/ログ/バックアップ先フォルダの権限問題（OS error 5 など）
SQL Server のサービスは、セットアップ時に指定したデータ/ログフォルダへ書き込みます。過去に手動でフォルダを触ったり、別ドライブの権限を強く絞ったりすると、サービスアカウントが書けずに失敗します。
対処の考え方はシンプルです。
- データ/ログ/バックアップ先のフォルダで、SYSTEM と Administrators がフルコントロールになっているか確認
- サービスアカウント（例：NT SERVICE\MSSQLSERVER または NT SERVICE\MSSQL$インスタンス名）に必要権限が付くようにする
権限の整備は GUI でもできますが、切り分け目的なら「まずはシンプルなパス」に戻すのが早いです。たとえば、インストール時にデータディレクトリを一時的に既定（C:\Program Files\Microsoft SQL Server\… 配下）へ戻して成功するか試すと、権限問題かどうかを切り分けできます。
原因C：Windows セキュリティ（ランサムウェア防止/フォルダーアクセス制御）によるブロック
Windows 11 では、Windows セキュリティの機能が強化されており、環境によっては SQL Server の書き込みがブロックされることがあります。ERRORLOG やイベントログにアクセス拒否が出る場合は特に要注意です。
- 「コントロールされたフォルダー アクセス」が有効で、SQL Server のプロセスが保護フォルダへ書けない
- セキュリティソフトがインストール直後の実行ファイルを隔離/監視して起動に失敗する
対処としては、インストール中だけ一時的に無効化して検証するか、SQL Server の実行ファイルを許可リストに追加するのが現実的です（恒久的に無効化するのではなく、検証→必要な許可設定に戻す流れを推奨します）。
原因D：再起動待ち（Pending reboot）や更新の影響
SQL Server のインストールや削除の途中で再起動が必要になっていると、次のセットアップで不整合が起きることがあります。セットアップログ側で「再起動が必要」などの文言が見えた場合は、いったん OS を再起動してから、もう一度クリーンな状態で進めます。
手動アンインストールで壊れた環境を“安全に”整理する手順
ここが最重要です。すでにファイル削除やサービス削除を手動で行っている場合、これ以上レジストリを深追いするほど状況が悪化することがあります。基本は公式の削除ルートに戻し、残骸が見える範囲を整えてから再インストールします。
ステップ1：残っているインスタンス/機能を可視化する
- SQL Server インストール センターで 「インストール済み SQL Server 機能の検出レポート」を確認（表示できるなら最優先）
- 「アプリと機能」または「プログラムと機能」で、SQL Server 関連が残っていないか確認
ステップ2：可能な限り「削除(Remove)」で落とす
SQL Server には “アンインストーラー” があり、インスタンス単位で削除できます。残骸があっても、使えるならそれが最優先です。
- 「Microsoft SQL Server 2022 (64-bit)」 → 変更 → 削除(Remove) → 対象インスタンスを選択
- 複数インスタンスがある場合は、不要なものから順に削除
ステップ3：サービスの残骸を確認する（services.msc）
Windows のサービスに以下が残っていないかを確認します。
- SQL Server (MSSQLSERVER)
- SQL Server (インスタンス名)
- SQL Server Browser
- SQL Server VSS Writer
- SQL Server Agent（エディション/構成による）
サービスが残っていても、むやみに削除するのではなく、まずは「公式の削除で消えるか」を優先します。どうしても消せない場合は、次の「再インストール前の整地」を行ってから判断します。
ステップ4：再インストール前の“整地”（やりすぎない）
やりすぎると逆効果になりやすいので、次の範囲に留めます。
| 対象 | 確認ポイント | 対応 |
|---|---|---|
| SQL Server のデータ/ログ/バックアップの置き場 | 過去のフォルダが残り、権限が特殊になっていないか | 必要なデータがないことを確認したうえで、フォルダを退避/整理（削除は慎重に） |
| Program Files 配下の残骸 | MSSQL16.<古いインスタンス> が多数残っていないか | 公式削除後も残る場合のみ、退避してから整理 |
| 再起動 | インストール/削除を繰り返した直後 | 必ず再起動して、保留中のファイル操作を確定させる |
注意：レジストリを直接掃除する系の手順は、再現性が低く事故が増えます。まずは上の範囲で“整うか”を試し、それでもダメなら OS 側の修復（システム整合性/更新、最終手段としての再セットアップ）を検討する方が安全です。
再インストールを成功させるためのチェックリスト
「一度壊れた環境」に再インストールするときは、毎回同じミスを避ける仕組みが大切です。次のチェックを、インストール前に一気に確認してください。
| チェック項目 | 確認方法 | 狙い |
|---|---|---|
| 管理者として実行 | setup.exe を右クリック → 管理者として実行 | 権限不足による失敗を回避 |
| 保存先ドライブの空き容量 | エクスプローラーで確認 | tempdb 作成失敗・展開失敗を回避 |
| データ/ログ配置先の単純化 | まずは既定、またはローカルの安定した物理ディスクへ | 権限/I/O/特殊レイヤー問題を避ける |
| セキュリティソフトの干渉 | インストール中のブロック履歴、隔離履歴 | 起動直後の exe/ファイル生成を妨害しない |
| Windows 更新と再起動 | Windows Update 適用後に再起動 | 保留中の更新や再起動待ちを解消 |
| SQL Server の更新（CU等） | インストール後に最新更新を適用 | 既知不具合の回避（起動/互換性） |
インストールが途中まで進んだ場合：サービスを手動で起動して“直接”エラーを見る
セットアップが失敗した直後でも、サービスが作成されていることがあります。その場合は、サービス起動を試すと原因が見えやすくなります。
- services.msc を開く
- 「SQL Server (MSSQLSERVER)」または「SQL Server (インスタンス名)」を探す
- 開始を試す（失敗したら表示されるエラーを控える）
- その直後に ERRORLOG の末尾を読む（起動に失敗した理由が書かれることが多い）
補足：サービスのエラー表示は大雑把なことが多いので、最後はやはり ERRORLOG が決め手です。
フォーラムや社内へ相談するときの“伝わる”情報のまとめ方
第三者に相談する場合、情報の出し方で解決速度が大きく変わります。最低限、次を揃えると回答が具体的になります。
- インストールが止まるフェーズ名（例：SQLEngineDBStartConfigAction_install_configrc_Cpu64）
- セットアップログ（該当フォルダの Summary/Detail、エラーコード）
- ERRORLOG（重要）：テキストとして共有しやすいよう、ERRORLOG を ERRORLOG.txt にリネームして添付する（中身は変わりません）
- データ/ログの配置先ドライブ、セクターサイズ情報（Get-PhysicalDisk の結果）
- 手動で削除した内容（サービス削除、フォルダ削除、複数インスタンス作成など）
特に ERRORLOG は“推測”を“確定”に変える材料です。相談の前に、まず ERRORLOG を押さえるだけでも解決が早まります。
まとめ：このエラーは「SQL Server が起動できない」サイン
「Could not find the database engine startup handle」「Wait on the Database Engine recovery handle failed」は、セットアップが止まっているように見えても、実態はSQL Server サービスが起動できていないことを示します。最初にやるべきことは、ERRORLOG を確認して真因を特定することです。
- ERRORLOG に「256 misaligned reads」がある → ディスク/セクター/ドライバー/配置先の問題を疑い、回避策（配置先変更など）で早期に切り分け
- それがない → 手動アンインストールの残骸、権限、セキュリティ機能のブロック、パス不整合を優先して点検
そして、過去に手動で削除して環境が崩れている場合ほど、無理なレジストリ掃除に進むよりも、公式の削除手順に戻して整地 → 再起動 → クリーンな再インストールの流れが安全で成功率が高くなります。
コメント