Windows Server 2012 R2で突然「Data collector set was not found」が出て、監視や診断が動かず、気づけば複数サービスまで停止――。本記事ではデータ コレクター セットの仕組みと確認方法、イベントログを使った原因特定、SFC/DISMによる修復、さらにSystem Stateとベアメタル回復(BMR)の整理まで、現場で迷わない手順をまとめます。
現象を整理：このエラーは何を意味するのか
「Data collector set was not found」は、Windowsのパフォーマンス モニター（perfmon）にあるデータ コレクター セット（Data Collector Set / DCS）を「開始しようとしたが、その定義が見つからない」場合に出やすいメッセージです。たとえば次のようなタイミングで遭遇します。
- perfmon の「システム」配下（System Diagnostics / System Performance など）を実行した
- 過去に作成した「ユーザー定義」DCSを、タスクやスクリプトから起動しようとした
- 監視ツールやベンダーツールが作ったDCSを参照していたが、後から削除・破損してしまった
重要なのは、このエラー表示そのものが「各種サービス停止」の直接原因とは限らない点です。現場では「DCSが見つからない」ことと「サービスが落ちた」ことが同時に起き、原因が1つに見えてしまいがちです。しかし、サービス停止を引き起こす根本原因（ディスク逼迫、OS破損、権限、依存関係、WMI不調など）が別に存在し、DCSエラーは“結果として目に付いただけ”というケースも多いです。
まず最優先：止まったサービスを特定し、イベントログで因果関係を掴む
「何が止まったのか」「いつから止まったのか」「何をきっかけに止まったのか」を最短で掴むには、イベントログが近道です。特にWindows Server 2012 R2のような長期運用環境では、複数要因が重なっていることが珍しくありません。
| 最初に確認する観点 | 具体的な確認ポイント | よく見つかる原因例 |
|---|---|---|
| サービス停止の実体 | 停止したサービス名、開始の種類（自動/手動/無効）、依存関係 | 依存サービス停止、アカウント変更、起動失敗の連鎖 |
| OSの健全性 | システムファイル破損、更新プログラム適用状況、再起動未完了 | コンポーネントストア破損、更新失敗 |
| リソース/ディスク | Cドライブ空き、PerfLogs肥大化、メモリ不足、ページファイル枯渇 | ディスク満杯でサービス停止、ログ書き込み失敗 |
| 監視/スクリプト | タスクスケジューラ、起動スクリプト、監視エージェントがDCSを参照していないか | 削除されたDCSを呼び出してエラー連発 |
停止サービスの洗い出し（GUIでもCLIでもOK）
GUIなら services.msc で「状態」「スタートアップの種類」を並べ替えれば概況が掴めます。CLIでまとめて見るなら、PowerShellの方が一覧性が高いです。
PowerShell（管理者）:
Get-Service | Sort-Object Status,Name
Get-Service | Where-Object {$_.Status -ne 'Running'} | Sort-Object Status,Nameイベントログの“当たり”を短時間で探す
まずは「Windowsログ」→「システム」「アプリケーション」を見ます。次に、DCS周りなら「アプリケーションとサービス ログ」配下も効きます。
| ログ | 見るポイント | 例 |
|---|---|---|
| Windowsログ > システム | Service Control Manager系（サービス起動失敗/停止）、ディスク/NTFS系 | サービスが開始できない、依存関係で停止 |
| Windowsログ > アプリケーション | アプリ固有エラー、.NET Runtime、アプリケーションログ出力失敗 | 監視エージェントや業務アプリの例外 |
| Microsoft-Windows-Performance-Logs-Alerts/Operational | PLA（Performance Logs and Alerts）関連の失敗 | DCS開始/停止失敗、出力先アクセス拒否 |
| Microsoft-Windows-TaskScheduler/Operational | スケジュール実行の成功/失敗、実行ユーザー、戻り値 | 削除済みDCSを呼び出すタスクが残っている |
| Microsoft-Windows-WMI-Activity/Operational | WMI問い合わせ失敗、遅延、エラーコード | WMI不調で監視や一部機能が壊れる |
サービス停止の原因を追うときは、「停止した時刻」±数分に絞って見るのがコツです。DCSエラーが出た時刻と、サービスが落ちた時刻が一致しているか／前後関係はどうかを確認し、相関ではなく因果を探します。
データ コレクター セットが“見当たらない”ときの確認ポイント
「パフォーマンス モニターを開いても、ユーザー定義などに目的のデータ コレクター セットがない」という場合、次のどれかに当たりやすいです。
- 参照しているDCS名が違う（大文字小文字、全角半角、前後スペース、監視ツール固有名）
- DCS定義が削除された／破損した
- PLAサービスが停止している／権限やWMI不調で一覧が取れていない
- “DCS”ではなく、ETWトレース セッション（ログマン）を参照している
GUIとコマンドで二重に確認する（logmanが強い）
GUI（perfmon）の表示が怪しいときは、logmanで定義を直接確認すると切り分けが速いです。
| やりたいこと | コマンド例 | ポイント |
|---|---|---|
| DCS一覧を出す | logman query | 登録済みのコレクター セット名を確認 |
| ETW（トレース セッション）も含めて確認 | logman query -ets | “セット”ではなくセッション参照の可能性を潰す |
| 特定名が存在するか確認 | logman query "（DCS名）" | 存在しないなら「not found」になりやすい |
| 開始/停止（存在している前提） | logman start "（DCS名）" logman stop "（DCS名）" | 権限不足や出力先アクセス拒否もここで判明 |
“DCSを呼び出している犯人”を探す
運用現場では、DCS自体が原因というより、削除されたDCSを呼び出し続けるタスクやスクリプトが残っていて、エラーが連発していることがあります。代表的には次の3箇所です。
- タスク スケジューラ（監視・定期診断・ログ収集系のタスク）
- 監視エージェントの設定（性能ログ採取機能、サポート用トレース）
- 運用スクリプト（起動時/日次で logman を叩くバッチ）
タスクの全量をざっくり眺めるなら、次のようなコマンドが手早いです。
schtasks /Query /FO LIST /V | findstr /i "logman perfmon PLA collector"出てきたタスク名を手がかりに、実行コマンドや引数にDCS名が含まれていないか確認します。
サービス停止まで発展する“ありがちな根本原因”
「DCSが見つからない」表示と同時期にサービスが止まる場合、現実的には以下の根本原因が潜んでいることが多いです。特に“結果的に各種サービスが停止した”という状況では、OSや基盤系サービスの不調を疑う価値があります。
| 根本原因の候補 | 症状の出方 | 確認方法 | 初動の対処 |
|---|---|---|---|
| ディスク容量逼迫（C:満杯、PerfLogs肥大） | サービスがログを書けず停止、更新が失敗、動作が不安定 | 空き容量、PerfLogs/Temp、イベントログのディスク/NTFS | 不要ログ退避、空き確保、ログ出力先変更 |
| システムファイル/コンポーネント破損 | 起動失敗が増える、サービスが連鎖停止、管理ツールの表示異常 | SFC/DISM、CBS.log/DISM.log | SFC→DISM、再起動、更新の整合性確認 |
| PLA / WMI など基盤サービスの不調 | perfmonが不安定、監視が動かない、DCS一覧が欠ける | pla/winmgmtサービス状態、関連ログ | サービス再起動、パフォカウンター再構築 |
| 権限/サービスアカウント問題 | 特定サービスだけ起動失敗、アクセス拒否が出る | イベントログのエラー、ログオン失敗、GPO変更履歴 | アカウント/パスワード/権限の再確認 |
| 監視ツールやジョブが暴走（高負荷） | CPU/メモリ逼迫→タイムアウト→サービス落ち | タスク/プロセス、リソースモニター、スケジュール | 監視設定見直し、採取頻度/項目削減 |
軽めの復旧から試す：SFC / DISM でOSの整合性を戻す
「DCSが消えた」ように見えても、実際はOSの破損や更新不整合が裏で起きていることがあります。まずは破壊的でない順に、システムファイル修復から着手するのが安全です。
SFC（システムファイル チェッカー）
sfc /scannow結果が「修復できないファイルがある」場合、ログは C:\Windows\Logs\CBS\CBS.log に残ります。すぐに深追いしなくても、次のDISMで改善することがあります。
DISM（コンポーネント ストア修復）
dism /online /cleanup-image /restorehealth環境によってはソースが見つからず失敗します（更新サーバーの構成やネットワーク制限など）。その場合は、インストールメディア（ISO）をマウントして /Source を指定すると通ることがあります。
例：D: がインストールメディアの場合
dism /online /cleanup-image /restorehealth /source:wim:D:\sources\install.wim:1 /limitaccessinstall.wim のインデックス番号は環境で異なるため、次のコマンドで確認します。
dism /Get-WimInfo /WimFile:D:\sources\install.wim再起動と再確認
SFC/DISM実行後は、可能なら再起動して、停止していたサービスが自動起動するか、イベントログに新しいエラーが出ないかを確認します。ここで改善したなら、DCSエラーも“二次的な症状”だった可能性が高いです。
パフォーマンス モニター周りの修復：パフォーマンスカウンターを再構築する
perfmon関連が壊れている場合、パフォーマンスカウンターの破損が影響していることがあります。サービス停止とは直接関係しないこともありますが、DCS周りの異常が続く場合は候補に入ります。
| 目的 | コマンド例 | 注意点 |
|---|---|---|
| パフォーマンスカウンターの再登録 | lodctr /R | 管理者で実行。状況によって再起動が有効 |
| WMIとパフォーマンスカウンターの同期 | winmgmt /resyncperf | WMI不調が疑われるときの補助。実行後にログ確認 |
これでも改善しない場合は、WMIリポジトリ自体の破損、または監視ツール側の設定破損も視野に入ります（WMIリポジトリ再構築は影響範囲が広いので、実施前にバックアップと影響評価を推奨します）。
データ コレクター セットが本当に消えた場合の対処
「特定のDCS名を起動しようとして not found」「logman query でも見つからない」なら、DCS定義が消えている可能性が高いです。対処は大きく2パターンです。
同等のDCSを作り直す（暫定復旧に強い）
監視やトラブルシュートで必要な最低限のカウンターだけでも採取できるよう、ユーザー定義で簡易DCSを作り直す方法です。例えばCPU/メモリ/ディスク/ネットワークを一定間隔で採るだけなら、短時間で再構成できます。
例（カウンターのセットを作成し、CSVで出力）：
logman create counter "QuickPerf" -f csv -si 00:00:15 -o "C:\PerfLogs\QuickPerf"
logman add counter "QuickPerf" "\Processor(_Total)\% Processor Time"
logman add counter "QuickPerf" "\Memory\Available MBytes"
logman add counter "QuickPerf" "\LogicalDisk(_Total)\% Free Space"
logman start "QuickPerf"サーバー負荷を上げないために、採取間隔（-si）と採取項目は控えめから始め、必要に応じて増やすのが現場的には安全です。
別環境から“同じDCS定義”を移植する（本復旧に強い）
同型のサーバーや検証環境に同じDCSが残っている場合、DCS定義をエクスポートして移植すると、監視・運用手順を崩さずに戻せます。移植が難しい場合は、監視ツール側でDCSを再作成できないか（修復インストール/再設定）が近道になることもあります。
System State とフルイメージ復元の整理：結論だけ先に
今回のやり取りの結論を、実務で使える形に言い換えると次の通りです。
- System State（システム状態）は、一般にベアメタル回復（BMR）の復元対象に含まれる
- つまり、OSを含むフルイメージ／ベアメタル復元を行う方式のバックアップなら、結果としてSystem Stateも戻ることが多い
- ただし、バックアップ製品や取得方式（ファイル単位、ボリューム単位、スナップショット方式など）で挙動が異なるため、「BMR対応のイメージか」を確認するのが安全
System Stateに含まれるもの（代表例）
System State は、ざっくり言うと「OSの動作に必要な中枢情報」です。代表例は次の通りです（サーバーの役割で増減します）。
- レジストリ
- ブートファイル
- システムファイル（保護されたファイル群）
- COM+ クラス登録
- （ドメインコントローラーの場合）Active Directory データベースやSYSVOL など
復元方式の違いを表で理解する
| 復元方式 | 戻る範囲 | 向いている場面 | 注意点 |
|---|---|---|---|
| ファイル/フォルダ復元 | 指定したファイルのみ | 誤削除、設定ファイルだけ戻したい | OS破損や基盤不調は直らないことが多い |
| ボリューム復元 | 特定ドライブ全体 | Dドライブ破損、ログ領域を丸ごと戻す | Cドライブ（OS）を戻さない限りSystem Stateは戻らない |
| System State 復元 | OS中枢情報 | レジストリ破損、役割関連の中枢が壊れた疑い | 単体復元の可否は製品/方式次第。DCは手順に注意 |
| ベアメタル回復（BMR）/フルイメージ復元 | OSを含むサーバー丸ごと | 短時間で元に戻したい、原因不明で広範囲に壊れている | 復元先互換性、ドライバ、ネットワーク設定の差分に注意 |
「フルイメージはあるがSystem Stateをどう扱う？」の実務回答
現場で迷いがちなポイントを、実務優先で整理します。
- 短時間で確実に元へ戻したい：BMR/フルイメージ復元が最短（復元後に原因追跡は別途）
- 原因を追いながら戻したい：SFC/DISM→ログ確認→必要箇所だけ復旧（ただし時間はかかる）
- バックアップ製品がSystem State単体復元に弱い：BMR前提で運用計画を立て、復元手順のリハーサルをしておく
復旧後にやっておくと再発が減る：運用の“地雷”を潰す
復旧できても、同じ条件が残っていると再発します。特に「DCSの削除/破損」「ログ領域の肥大化」「監視タスクの参照ズレ」は再発率が高いので、復旧後に一度だけでも棚卸しすると効果的です。
| チェック項目 | 確認内容 | 改善アイデア |
|---|---|---|
| PerfLogsの容量 | C:\PerfLogs 配下のサイズ、保存期間、出力先 | 出力先を別ドライブへ、ローテーション/削除ルール |
| DCS定義の保全 | 重要DCS名、採取項目、開始条件 | 定義をエクスポートして変更管理、復元手順書化 |
| タスクスケジューラ | logman/perfmonを呼ぶタスク、実行アカウント、失敗履歴 | 不要タスク停止、失敗時通知、実行頻度の最適化 |
| 更新と再起動 | 適用失敗、保留中の再起動、WSUS設定 | 更新運用の整備、メンテ枠で計画再起動 |
| サポート終了への備え | 現行のセキュリティリスクと運用コスト | 上位OSへの移行計画、VM化/リプレースの検討 |
よくある質問（現場で詰まりがちなポイント）
「ユーザー定義」にも何もない。DCSはどこに消えた？
本当に削除されている場合もありますし、PLAサービスやWMIの不調でGUI表示が欠けている場合もあります。まずは logman query で一覧を取り、存在そのものを確認してください。GUIに見えないのにlogmanに出るなら、表示側の問題（管理ツール/WMI）を疑う方が早いです。
「Data collector set was not found」が出るのに、サービス停止のログが見つからない
サービス停止のログが「システム」に出ない場合、アプリが自分で停止している、あるいは監視ツールが停止/再起動をかけていることがあります。アプリケーションログ、監視ツールのログ、タスクスケジューラの実行履歴まで範囲を広げてください。
SFC/DISMを回しても改善しない。次は何を疑う？
次の優先候補は「ディスク逼迫」「権限/アカウント」「WMI/PLA」「監視タスクの暴走」です。特にCドライブ空きとPerfLogs肥大は、トラブル時に最も効率よく刺さる確認ポイントです。
フルイメージがあるなら、System Stateの個別バックアップは不要？
“災害復旧（DR）”を主目的にするなら、BMR可能なフルイメージが中心で運用しやすいです。一方で、ドメインコントローラーなど役割によってはSystem State単体復元を使う場面が出ることがあります。自社のバックアップ製品で「何ができるか」「復元に必要な手順・前提」を一度検証しておくのが安全です。
まとめ：エラー文に引っ張られず、ログと整合性修復で“本丸”を潰す
「Data collector set was not found」は、DCS定義の欠落・破損で出る典型的なメッセージですが、サービス停止まで発展しているなら、まずはイベントログで停止サービスと原因を特定し、SFC/DISMでOS整合性を戻すのが現実的です。そのうえで、DCSが消えているなら作り直しや移植、そしてバックアップはBMRとSystem Stateの関係を理解して“戻せる状態”を担保しておく——この順番で進めると、復旧までの時間と再発率を同時に下げられます。
コメント