Microsoft Defenderのサービスが停止して見える場合は、最初に「その端末でDefenderが主担当のウイルス対策か」を確認します。他社製品との併用、パッシブモード、起動後に停止するドライバーを、すべて故障と扱わないでください。保護が想定どおり動いていない端末では、実際の保護状態と管理ポリシーを照合してから復旧します。
最初に区別する：Windowsセキュリティの表示とAVの動作モード
| 確認事項 | 見る理由 |
|---|---|
| 主担当のウイルス対策製品 | Defenderを有効にする設計か、別製品を使う設計か |
| OSとバージョン | WindowsクライアントとWindows Serverで併用動作が異なる |
| Defender for Endpointへのオンボード | パッシブモード等の条件に関係する |
| GPO・Intune・ConfigMgrなどの管理元 | ローカル変更が管理設定で戻される場合がある |
| 実際の警告・最終更新・エラー時刻 | 古い警告やUI不具合と、現在の保護停止を分ける |
Windows 10/11で別のウイルス対策製品が主担当の場合など、Defender Antivirusが無効になることは設計上あり得ます。パッシブモードと無効モードも同じではありません。Microsoftの互換性表で、そのOS・製品・オンボード状態に対応する行を確認してください。
サービスとドライバーは読み取りから始める
管理者のPowerShellで、まず現在の状態を取得します。次のコマンドは確認用で、起動種類を一括変更しません。
Get-Service WinDefend, WdBoot, WdFilter, WdNisSvc, WdNisDrv, SecurityHealthService, wscsvc |
Format-Table DisplayName, Name, StartType, Status -AutoWdBootが起動後にStoppedになっていること自体は正常です。一覧のすべてをRunningにすることを復旧目標にしないでください。WinDefend等は主担当・パッシブ等の想定モードと比較し、SecurityHealthService等の画面通知に関わる状態とも区別します。
利用可能な環境では次も読み取ります。値が取得できない場合は、そのエラー自体を記録し、同じ構成の正常端末や管理コンソールと比較してください。
Get-MpComputerStatus | Select-Object AMRunningMode, AntivirusEnabled, RealTimeProtectionEnabled, AntivirusSignatureLastUpdated, IsTamperProtectedイベント5007と5001の読み方
「Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational」で、発生時刻と前後のイベントを確認します。5007は構成変更、5001はリアルタイム保護の無効化に関する情報です。5007があるだけでマルウェア感染と断定せず、ポリシー更新や管理者の作業記録と照合します。
- 警告が出た時刻と、サービスが停止した時刻をそろえる。
- 変更前後の値、関連するエラーコード、プラットフォーム版を記録する。
- 同じ更新・同じ管理設定の端末でも起きるかを確認する。
- 予期しない設定変更がある場合は、組織のインシデント対応手順に従って調査する。
復旧は対象と管理元を確認して段階的に進める
- まず必要な更新や再起動待ちを確認し、管理で指定されている保護更新の配布経路を確認します。
- 主担当を他社製品からDefenderへ移す場合は、ベンダーの正式なアンインストール・移行手順を使います。保護が途切れる期間を管理し、別製品を無断で削除しません。
- 管理設定の競合があれば、GPO・Intune等の設定元で整合させます。ローカルレジストリだけを削除して復旧扱いにしません。
- プラットフォームのリセットや定義の削除が必要な場合は、公式の起動問題手順と対象版を照合し、復旧用の更新経路と戻し方を準備して実施します。
Microsoftの公式資料には、定義の削除やポリシーの退避・削除を含む高度な復旧操作も掲載されています。ただし、本番のすべての端末へ同じ操作を配布するための手順ではありません。対象端末の設定と保護の再有効化を管理者が確認できる場合に限り、公式の起動問題手順を参照してください。
改ざん防止で設定が変わらないとき
改ざん防止は重要な保護設定の変更を制限します。操作が反映されないからといって、サービスやレジストリの権限を奪って強制変更しないでください。管理者は改ざん防止の公式案内に沿い、必要な診断と正規の管理経路を使います。作業後は保護が想定の状態に戻っていることを確認します。
更新経路と展開後の確認
セキュリティインテリジェンスの更新、エンジン、プラットフォームは役割が異なります。Windows Update、WSUS、Configuration Manager等を使う組織では、端末の更新先と承認状況を確認します。インターネット直結の更新をすべての端末へ強制する前に、配布方針と通信条件を確認してください。保護更新の配布元と優先順が参考になります。
復旧の判定は「サービスを開始できた」だけでは足りません。想定モード、リアルタイム保護、更新時刻、改ざん防止、再起動後の継続動作、管理コンソールの状態まで確認します。試験端末で検証してから範囲を広げ、失敗時は変更を重ねず記録を基に調査します。
問い合わせ・社内記録に残す情報
- OS・Defenderの版、主担当AV、MDEオンボード状態
- 管理元と適用ポリシー、想定モードと実測値
- 警告文・イベントID・発生時刻・変更前後の値
- 更新経路、直前の変更、再現する端末の範囲
- 実施操作と結果、再起動後の確認
資料の更新日が新しいことは、同じ日に新しい製品障害や脆弱性が発生した証拠ではありません。この記事はサービス起動問題の確認手順として利用し、特定の障害発生日やCVEの告知とは区別してください。
コメント