Windows Server 2016 に 2020-07 Servicing Stack Update（KB4565912）を適用した後、脆弱性スキャナから「NetSetupApi.dll（10.0.14393.3801）が見つからない」と指摘されることがあります。WinSxS には存在するのに System32 にない場合、どこを確認し、どの順で対処すべきかを実務目線で整理します。
現象と背景
今回のトラブルは、Windows Update 自体は正常完了しているのに、スキャナの判定だけが「必要な DLL がない」となってしまうタイプです。典型的には次のような状況が重なります。
- 対象 OS：Windows Server 2016（GUI / Server Core いずれも起こり得る）
- 適用した更新：2020-07 Servicing Stack Update（KB4565912）
- スキャナの指摘：NetSetupApi.dll（10.0.14393.3801）が「存在しない」または「本来あるべき場所にない」
- 実態：WinSxS（コンポーネントストア）配下には NetSetupApi.dll が見つかる
- 悩みどころ：「WinSxS から System32 にコピーしてよいのか？」
結論から言うと、いきなり WinSxS から System32 へ手動コピーするのは推奨しません。ただし、状況次第では「正しい手順で置き換える」ことが落としどころになるケースもあります。そのため、本記事では安全寄りの切り分け→修復→誤検知の確認→最終手段の順に整理します。
KB4565912がServicing Stack Updateであることを確認する
まず大前提として、KB4565912 は Servicing Stack Update（SSU）です。SSU は Windows Update を「インストールする仕組み（サービススタック）」を更新するもので、通常の累積更新とは性質が異なります。
| 項目 | ポイント | 実務上の意味 |
|---|---|---|
| 更新の種類 | SSU（Servicing Stack Update） | 更新の適用のされ方が通常の更新と違うため、ファイルの見え方がズレることがある |
| アンインストール | デバイスからアンインストール不可 | 「戻して検証」ができない。切り分けは別ルートが必要 |
| 再起動 | 適用に再起動が必須ではない | 再起動しないままスキャンすると差分が残って見えることがある（環境依存） |
| 適用対象 | Windows 10 1607 / Windows Server 2016 など | 同系統のファイルバージョン（10.0.14393.xxxx）で語られる |
また、Microsoft サポートのファイル情報欄には、KB4565912 によりインストールされるファイルとして Netsetupapi.dll（10.0.14393.3801） が掲載されています。つまり、「そのバージョンの NetSetupApi.dll を期待する」こと自体は筋が通っています。
WinSxSとSystem32の関係を理解する
WinSxS は「不要だから消していいフォルダ」ではなく、Windows のコンポーネントストアです。多くのシステムファイルは WinSxS 側に実体があり、System32 側はハードリンクで参照しているケースがあります（＝見た目は System32 にファイルがあるが、実体は WinSxS と同一）。
| 場所 | 役割 | 特徴 | 注意点 |
|---|---|---|---|
| C:\Windows\WinSxS | コンポーネントストア（本体） | 複数バージョンの部品を保持し、修復や更新の土台になる | 手動削除は厳禁。削除すると起動不能や更新不能になり得る |
| C:\Windows\System32 | 実行時に参照される主要パス | WinSxS の実体へハードリンクされている場合がある | 手動で差し替えると整合性崩れや将来更新の失敗につながり得る |
| C:\Windows\SysWOW64 | 32bit コンポーネントの主要パス | 64bit OS 上の 32bit 互換環境 | スキャナ/エージェントが 32bit の場合、こちらだけ見て誤判定することがある |
重要
WinSxS にファイルがある＝そのままコピーしてよい、ではありません。
「本来あるべきリンクが壊れている」のか、「スキャナが参照すべき場所を誤っている」のかで、最適解が変わります。
まずやるべき切り分け
最初にやるべきことは、“本当に存在しない” のか、 “場所や見方の問題” なのかをはっきりさせることです。ここが曖昧だと、手動コピーで「たまたま直ったように見える」けれど後で別障害になる、という事故が起きます。
ファイルの有無とバージョンを確認する
PowerShell で「System32 にあるか」「WinSxS にあるか」「バージョンが何か」を確認します。
### System32 の存在確認
Test-Path "$env:windir\System32\NetSetupApi.dll"
### SysWOW64 の存在確認（32bit 側）
Test-Path "$env:windir\SysWOW64\NetSetupApi.dll"
### WinSxS 内を検索（時間がかかるので必要なときだけ）
Get-ChildItem "$env:windir\WinSxS" -Filter NetSetupApi.dll -Recurse -ErrorAction SilentlyContinue |
Select-Object -First 10 FullName
### バージョン確認（存在するパスを指定）
(Get-Item "$env:windir\System32\NetSetupApi.dll").VersionInfo | Select-Object FileVersion, ProductVersion
### 署名確認（改変・破損の疑いをつぶす）
Get-AuthenticodeSignature "$env:windir\System32\NetSetupApi.dll" | Select-Object Status, SignerCertificateスキャナの表現が「見つからない」でも、実態としては次のパターンがあり得ます。
- パターンA：System32 にファイル自体が存在しない（本当に欠落）
- パターンB：System32 にはあるが、バージョンが古い（スキャナが “未適用” を “欠落” と表現）
- パターンC：System32 ではなく SysWOW64 を見ている（エージェントが 32bit、または判定ロジックが固定）
- パターンD：ファイルはあるが、権限/隔離/EDR の影響でスキャナが読めず “欠落扱い”
ハードリンクの有無を確認する
System32 側にファイルがある場合、それが WinSxS の実体とリンクしているか確認すると、コンポーネントストア整合性の判断材料になります。
fsutil hardlink list C:\Windows\System32\NetSetupApi.dll一覧に WinSxS 配下のパスが出てくるなら、System32 側は WinSxS と同じ実体を参照している可能性が高いです。逆に、System32 側が存在しない・リンクが壊れているなら、次章の SFC/DISM での修復を優先します。
推奨の対応フロー
リスクの低い順に並べると、基本方針は次の通りです。
| 優先度 | 対応 | 狙い | 判断の目安 |
|---|---|---|---|
| 高 | 現状確認（存在/バージョン/署名/リンク） | 「欠落」か「誤検知」かを分ける | System32 と SysWOW64 の両方を確認 |
| 高 | SFC（sfc /scannow） | Windows Resource Protection の範囲で修復 | まずはこれが最も安全 |
| 中 | DISM（RestoreHealth） | コンポーネントストアの破損を修復 | SFC で直らない/実行できない場合 |
| 中 | スキャナ側の条件確認 | 判定ロジックの誤り・古いプラグインを疑う | OS は正常で、ファイルも存在するのに指摘が残る場合 |
| 低 | 最終手段としての手動置き換え | どうしても検知を消す必要がある場合の回避 | 影響範囲を理解した上で、変更管理のもとで実施 |
SFCでシステムファイルを修復する
Microsoft Learn の Q&A でも、まず sfc /scannow で整合性を確認する流れが案内されています。
sfc /scannowSFC を実行したら、次の観点で結果を確認します。
- 「整合性違反は見つかりませんでした」→ OS 側は概ね健全。スキャナ誤検知の可能性が上がる
- 「破損したファイルを修復しました」→ 再起動して再スキャン
- 「一部修復できませんでした」→ DISM を検討（次章）
特に System32 側のファイル欠落が原因なら、SFC で復元されることがあります。まずはここで「Windows の正規ルートで戻るか」を試すのが安全です。
DISMでコンポーネントストアを修復する
SFC で解決しない場合、コンポーネントストア（WinSxS）の破損が疑われます。DISM の RestoreHealth は、その “修復元” を整える手段です。
DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealthサーバがインターネットに出られない、WSUS 運用、Windows Update が閉じているなどで RestoreHealth が失敗する場合は、インストールメディア等を Source として指定します（環境によって WIM のインデックス番号が異なります）。
DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:D:\sources\install.wim:2 /LimitAccessDISM が完了したら、もう一度 SFC を回すと整合性が揃いやすいです。
sfc /scannowここまでが、Windows の修復機構に沿った “安全寄り” の王道です。これで System32 へのリンクが戻るなら、手動コピーを避けられます。
脆弱性スキャナの誤検知を疑うポイント
OS の修復が通っても指摘が残る場合は、スキャナ側の前提がズレている可能性を疑います。特に SSU は「KB を入れた＝必ず System32 にその DLL が見える」とは限らず、判定の作りが粗いと誤検知が起きやすいです。
スキャナ側で起こりがちなズレ
| ズレの種類 | 起きること | 確認方法 | 対処の方向性 |
|---|---|---|---|
| 参照パス固定 | System32 しか見ない／WinSxS を見ない | ベンダーの検知仕様・プラグイン内容を確認 | プラグイン更新、検知条件の調整、例外設定 |
| 32bit/64bit の混同 | SysWOW64 を見て「ない」と判断 | エージェントのビット数、参照ディレクトリ | 正しいビット数のエージェントに変更、検知改善 |
| KB とファイルのマッピングが古い | 後続更新でバージョンが変わっているのに追随しない | スキャナのシグネチャ更新日、プラグインの更新履歴 | 最新のプラグインへ更新、再スキャン |
| 権限不足/隔離 | 読めない＝欠落扱い | スキャナ実行ユーザー権限、EDR ログ | 権限付与、除外設定、実行方式の見直し |
KBのインストール状態を確認する
「Windows Update 履歴では入っている」に加えて、パッケージとしての状態を確認するとスキャナとの会話が早くなります。
DISM /Online /Get-Packages /Format:Table | findstr 4565912SSU はアンインストールできない性質があるため、「入っているのに戻せない」のは正常挙動です。
最終手段として手動置き換えを行う場合
Microsoft Learn の Q&A では「古いファイルを新しい版で置き換え、regsvr32 を実行する」という回答が受理されています。
ただし実務では、手動置き換えは “最終手段”として扱うのが安全です。理由は次の通りです。
- System32 は保護対象で、更新適用・整合性チェックの前提が崩れることがある
- 誤ったアーキテクチャ（amd64 / wow64）を置くと、別の障害を誘発する
- スキャナの誤検知が原因の場合、置き換えても根本解決にならない
実施前の必須事項
1) フルバックアップまたはスナップショット取得
2) 変更管理（作業手順・ロールバック手順・承認）
3) メンテナンス時間確保（再起動が必要になる可能性を織り込む）
置き換えで事故を起こさないためのポイント
- WinSxS 内に複数の NetSetupApi.dll が存在し得るため、必ずバージョン（10.0.14393.3801）と署名を確認する
- 64bit OS では、System32 は 64bit、SysWOW64 は 32bit。置き換える先と元の DLL の整合を取る
- コピー前に、現行ファイルを必ず退避（.bak など）する
- 置き換え後は SFC を回して、OS の整合性を再チェックする
作業例としての考え方
具体的なコマンドや手順は、環境の構成（EDR、監査、権限設計、運用ルール）で変わるため、ここでは “やるなら最低限ここを守る” という観点で示します。
- WinSxS から候補を探し、ファイルバージョンと署名を確認する
Get-ChildItem "$env:windir\WinSxS" -Filter NetSetupApi.dll -Recurse -ErrorAction SilentlyContinue | ForEach-Object { $v = $_.VersionInfo.FileVersion if ($v -like "10.0.14393.3801*") { $_ } } | Select-Object -First 5 FullName # 署名確認（候補パスを指定） Get-AuthenticodeSignature "（ここに候補パス）" | Select-Object Status, SignerCertificate - System32 側の現行ファイルの有無とバージョンを記録する（存在する場合）
(Get-Item "$env:windir\System32\NetSetupApi.dll" -ErrorAction SilentlyContinue).VersionInfo | Select-Object FileVersion, ProductVersion - 置き換え後に SFC を実行し、Windows の整合性で問題が出ていないか確認する
sfc /scannow
「コピーしてよいか？」の問いに対しては、運用の現場感としてはこう整理できます。
| 状況 | 推奨度 | 理由 |
|---|---|---|
| SFC/DISM 未実施 | 低 | まず正規の修復ルートを試す方が安全 |
| SFC/DISM で修復不能、かつ System32 欠落が原因で業務影響が出ている | 中 | 変更管理の上で最終手段として検討余地 |
| OS は正常、スキャナだけが指摘し続ける | 低 | ファイル改変より、検知条件・プラグイン更新・例外が合理的 |
regsvr32を実行する場合の注意
Q&A では置き換え後に regsvr32 netsetupapi.dll を実行する案内があります。
ただし regsvr32 は万能ではありません。Microsoft サポートでも、regsvr32 は DLL や ActiveX コントロールなどの OLE コントロールを登録・登録解除するためのコマンドであることが説明されています。つまり、対象 DLL が登録を前提としていない場合、実行してもエラーになります。
64bit OSではregsvr32が2種類ある
64bit 版 Windows には regsvr32 が 2 種類存在します。
- 64bit 版：%systemroot%\System32\regsvr32.exe
- 32bit 版：%systemroot%\SysWOW64\regsvr32.exe
どちらを実行すべきかは「登録したい DLL が 64bit か 32bit か」に依存します。誤ると意図しない場所に登録情報が入ったり、エラーの切り分けが難しくなります。
regsvr32でよくあるエラーと判断
- DllRegisterServer エントリポイントが見つからない：その DLL は regsvr32 登録対象ではない可能性が高い。無理に続行しない
- アクセスが拒否されました：管理者権限不足、またはセキュリティ製品の制御。権限とログを確認
- モジュールの読み込みに失敗：依存 DLL 不足やアーキテクチャ不一致の疑い
要するに、regsvr32 は “やれば直る魔法” ではなく、必要な DLL にだけ意味がある作業です。今回の目的は「ファイル欠落/不整合の解消」なので、regsvr32 は補助的に考え、まず SFC/DISM とスキャナ側の条件確認を優先するのが安全です。
作業前後のチェックリスト
本番サーバで触る場合、次をチェックしておくと事故率が下がります。
作業前
- バックアップ/スナップショット取得
- 影響範囲確認（ドメインコントローラ、DHCP、DNS、クラスタ等の役割）
- メンテナンス時間の確保（再起動を含む）
- スキャナのプラグイン/シグネチャ更新（可能なら先に更新して再スキャン）
作業後
- SFC 実行結果の確認
- イベントログ（System / Application）の確認
- 再起動後のサービス稼働確認
- 脆弱性スキャンの再実施と、検知内容の文言比較
WinSxSを触るときの追加注意
今回の話題で WinSxS が出てくると、「容量が大きいから削除したい」という話がセットで出がちです。しかし、Microsoft Learn では WinSxS フォルダを削除してはいけないこと、削除すると起動不能や更新不能になり得ることが明確に警告されています。容量問題は削除ではなく、組み込みのクリーンアップ手段で対処します。
よくある質問
KB4565912がアンインストールできません。失敗ですか？
失敗ではありません。SSU は更新の仕組み自体を更新するため、アンインストールできない仕様です。
WinSxSにあるなら、System32にコピーしても同じでは？
見た目は同じでも、Windows の保護機構（整合性・署名・リンク構造）を壊す可能性があります。まずは SFC/DISM で正規ルートの修復を試し、それでも解決しない場合に、変更管理の上で最終手段として検討するのが安全です。
System32にファイルがあるのにスキャナが「ない」と言います
参照パス固定、32bit/64bit の混同、権限不足、プラグインの古さが代表的です。System32 と SysWOW64 の両方を確認し、スキャナの実行権限・エージェントのビット数・シグネチャ更新状況をチェックしてください。
コメント