Windows Server 2019でWinDRBDが入らない・起動しない（1.1.20導入失敗／1.1.7で0xc000014f）原因切り分けと復旧チェックリスト

同じインストーラーが「他の同一構成サーバーでは正常に動くのに、特定ノードだけWinDRBD 1.1.20がインストール完走しない」「1.1.7は入るが drbdadm.exe 実行で “0xc000014f”」——この手の“1台だけ壊れる”問題は、だいたい OS更新差分・セキュリティ強化（Hardening）差分・ランタイム/署名/実行制御・ディスク/ファイルシステムの異常のどれかです。この記事では、再現条件が曖昧でも前に進められるように、ログの取り方から差分確認、直し方までを手順化します。

• Windows Server 2019でWinDRBDが入らない・起動しない（1.1.20導入失敗／1.1.7で0xc000014f）原因切り分けと復旧チェックリスト
  • 前提整理：起きていることから見える「当たりどころ」
  • まず最優先：ログを取り切る（原因の8割がここで確定する）
    • 1) インストーラーログ（%TEMP%）を回収
    • 2) WinDRBDのドライバログ（windrbd-kernel.log）
    • 3) ドライバ導入の標準ログ（setupapi.dev.log）
  • 「1台だけ違う」を潰す：差分の王道チェック
    • A. OS更新・コンポーネントストア破損
    • B. Visual C++ 再頒布可能パッケージ（VC++ Runtime）差分
    • C. 実行制御（WDAC/AppLocker）とEDR/AVのブロック
    • D. VBS/HVCI（メモリ整合性）などのHardening
  • 0xc000014f の読み方：実は「ファイルシステム/ボリューム異常」線もある
  • 実践：この順で潰すと早い（最短ルート）
  • まとめ：1.1.20導入失敗＋1.1.7起動不可は「環境側のブレーキ」が本命

前提整理：起きていることから見える「当たりどころ」

• 1.1.20：インストールが完走しない
  → MSI/セットアップが途中で止まる、ドライバ導入で失敗する、実行制御に止められる、%TEMP%や書き込み先が壊れている、などが濃厚。

• 1.1.7：drbdadm.exe が 0xc000014f で起動しない
  → 依存DLLの欠落/破損、実行ファイルが置かれているボリュームの問題、アプリ制御（WDAC/AppLocker等）によるブロック、システムファイル破損が疑いどころ。

なお、WinDRBDはログの置き場が明示されています。ドライバログは C:\windrbd\windrbd-kernel.log、インストーラーログは %TEMP% に出力されるため、まずここを確保します。 GitHub

まず最優先：ログを取り切る（原因の8割がここで確定する）

1) インストーラーログ（%TEMP%）を回収

WinDRBDはインストーラーが %TEMP% にログを書きます。インストールが途中で失敗する場合、ここに「どの段で落ちたか」が残ります。 GitHub

• 失敗ノードで、管理者権限のPowerShellを開き、$env:TEMP 配下の最新ログを保存

• 併せて イベントビューアー

  • Windowsログ > アプリケーション（MsiInstallerのイベント）

  • Windowsログ > システム（ドライバ/サービス起動失敗）

  • アプリケーションとサービスログ > Microsoft > Windows > CodeIntegrity / AppLocker / WDAC関連（あれば）

2) WinDRBDのドライバログ（windrbd-kernel.log）

C:\windrbd\windrbd-kernel.log を確認。さらに windrbdlog サービスが起動していることも合わせて確認します。 GitHub

3) ドライバ導入の標準ログ（setupapi.dev.log）

ドライバが入らない系はここが決定打になりやすいです。

• C:\Windows\INF\setupapi.dev.log

「1台だけ違う」を潰す：差分の王道チェック

同一構成のはずでも、実際は次がズレていることが多いです。

A. OS更新・コンポーネントストア破損

• 失敗ノードだけWindows Updateが滞留、もしくはコンポーネントストアが破損していると、インストーラーや署名検証が不安定になります。

• 修復の定番（管理者で実行）：

• さらにディスクの整合性も確認：

B. Visual C++ 再頒布可能パッケージ（VC++ Runtime）差分

drbdadm.exeがC/C++製なら、VC++ランタイム差分で「起動だけ失敗」が起きます。Microsoftは「2017以降は同系統のv14再頒布が共有され、アプリが要求する版以上が必要」と説明しています。 Microsoft Learn+1

• “正常ノードに入っていて失敗ノードに無い” を疑う

• x64/arm64/x86の取り違えも要注意（Server 2019なら基本x64）

C. 実行制御（WDAC/AppLocker）とEDR/AVのブロック

「インストール途中で止まる」「特定EXEだけ起動しない」は、WDAC/AppLockerやEDRが刺さっている典型です。

• AppLockerログ、WDAC（Code Integrity）ログを確認

• 一時的に検証用として、該当ポリシーが適用されていないOUに移す／例外ルールを作る（本番運用の方針に従って）

D. VBS/HVCI（メモリ整合性）などのHardening

カーネルドライバ系はここが大きな地雷です。Microsoftのドキュメントでも、**仮想化ベースのコード整合性（Memory integrity / HVCI）**はコード整合性保護の仕組みとして明示されています。 Microsoft Learn

• 失敗ノードだけ「メモリ整合性ON」「Device Guard有効」になっていないか確認

• 署名やロード方式によってはドライバ初期化が止まります

※補足：WinDRBDは“テスト署名モードが必要”という記述があり、未署名ドライバをロードする場面では bcdedit /set TESTSIGNING ON が登場します。 GitHub
（市販/提供バイナリが署名済みなら通常は不要ですが、「何らかの理由で署名検証が通っていない」ケースの切り分け材料になります。）

0xc000014f の読み方：実は「ファイルシステム/ボリューム異常」線もある

0xC000014F はNTSTATUSで **STATUS_UNRECOGNIZED_VOLUME（認識できないボリューム）**として定義されています。 Microsoft Learn+2winprotocoldoc.z19.web.core.windows.net+2
アプリ起動時にこのコードが出るのは珍しく見えますが、現場では次のような形で起きえます。

• drbdadm.exe や依存DLLが置かれているドライブが、フィルタドライバやストレージ異常で“瞬間的に”おかしくなる

• %TEMP% やプロファイルがリダイレクトされていて、そこが不安定

• セキュリティ製品がファイルを隔離し、結果として「ロードすべきものが読めない」

確認ポイント

• WinDRBDのインストール先（既定は C:\windrbd）がローカルNTFSか

• %TEMP% がネットワークドライブ/特殊ボリュームに向いていないか

• イベントビューアーのディスク/NTFS/StorPort関連警告が出ていないか

実践：この順で潰すと早い（最短ルート）

1. 失敗ノードで %TEMP% のインストーラーログ、setupapi.dev.log、windrbd-kernel.log、イベントログ（MsiInstaller/CodeIntegrity/AppLocker）を回収 GitHub

2. OS更新差分を解消（最新累積更新を適用→再起動）

3. DISM/SFC/CHKDSK で基盤の破損を修復

4. VC++ v14（2015–2022/以降の系統）再頒布を“正常ノードと同水準”へ Microsoft Learn+1

5. Hardening差分の確認（WDAC/AppLocker、VBS/HVCI、EDRの隔離ログ） Microsoft Learn

6. それでもだめなら、「正常ノードと失敗ノードの差分（更新履歴・適用GPO・インストール済みランタイム）」を表で潰す

   • “同一”は思い込みで、差分が必ずあります

まとめ：1.1.20導入失敗＋1.1.7起動不可は「環境側のブレーキ」が本命

今回の症状は、アプリのバージョン差というより **その1台のWindows Server 2019だけが抱える差分（更新不足/破損/実行制御/ドライバ整合性/ストレージ周り）**が原因である可能性が高いです。
ログ（%TEMP%、setupapi.dev.log、windrbd-kernel.log、CodeIntegrity/AppLocker）を揃え、OS基盤→ランタイム→Hardening→ボリューム健全性の順に潰すと、遠回りせずに原因へ到達できます。 GitHub+1