Kernel-EventTracingのイベントID 2に「次のエラーのため、セッションを開始できませんでした: 0xC0000035」と出た場合、まず記録されたセッション名・日時・実際の症状を確認します。0xC0000035は名前の重複を示すコードです。イベントだけでPCの故障やブルースクリーンの原因とは確定できません。ログを削除したりWindowsのトレースを停止したりする前に、下記の読み取りによる確認を進めます。
Kernel-EventTracing イベントログ (Event ID 2) で発生する 0xC0000035エラーとは？
Kernel-EventTracing (Event ID 2) はETW（Event Tracing for Windows）の開始失敗を記録する場合があります。「Session "SensorFramework-xxxxxx" failed to start with the following error: 0xC0000035.」などの文面では、引用符内がセッション名、末尾がエラーコードです。名前が違うイベントは別々に記録して確認します。
0xC0000035 (STATUS_OBJECT_NAME_COLLISION) の意味
MicrosoftのNTSTATUS一覧で、0xC0000035は「オブジェクト名が既に存在する」という意味です。ETWのStartTrace仕様でも、セッション名は一意である必要があり、同名または同じGUIDのセッションが実行中なら開始が失敗すると説明されています。StartTraceの戻り値ERROR_ALREADY_EXISTSと、ログ内のNTSTATUSコードは別の表記です。
同じ名前の開始処理が重なっていないかを確認する手掛かりですが、なぜ重なったかや、どのアプリが開始したかまではこのコードだけで分かりません。センサードライバー・WMI・ウイルスなどを名前から決めつけず、発生条件を調べます。
MPWppUpdateLogging・PerfDiag Loggerなど、名前が違う場合
| ログ内の名前の例 | 記録すること | 名前だけでは判断できないこと |
|---|---|---|
| MPWppUpdateLogging | エラー全文・発生時刻・同時刻の症状 | どの更新が原因か、対策ソフトが停止したか |
| PerfDiag Logger | 同じ名前で繰り返すか、起動時だけか | PCのフリーズやブルースクリーンの直接原因か |
| DefenderApiLoggerLowPriv | 同時刻のセキュリティ状態と別の警告 | このイベントだけで保護が無効になったか |
| SensorFramework-… | 末尾を含めた完全な名前 | センサーの故障や特定ドライバーの不具合か |
これらに共通の「名前を消せば直る」という手順はありません。保護機能やOSのログ設定を無効にせず、対象PCの記録から確認します。
エラー発生の影響範囲
イベントが単独で出る場合と、同時刻にアプリ停止・通信断・再起動などが起きる場合を分けます。症状がないときは、発生頻度や更新前後の差を記録して管理者へ相談できます。症状があるときは、その症状に対応するログや停止コードも調べます。同時刻に記録されたことだけで因果関係は確定しません。
実運用で見逃しがちなポイント
運用管理者の方が見落としがちなポイントとして、イベントログは普段から監視していないと「必要になったときに急いで調べる」という場面が多いことが挙げられます。そのため、ひとたび Kernel-EventTracing のエラーが連続的に記録されるようになると「何が原因なのか把握できないまま放置されがち」という状況に陥りやすいのです。監視体制の強化や定期的なログチェック体制が望まれます。
よくある原因と対処策
まず変更を伴わない確認を行います。すべての対策をまとめて実行すると、どの変更が影響したか分からなくなります。自分が管理する収集処理とWindows・製品側の処理を区別して進めてください。
1. 既存の ETW セッションを読み取りで確認
管理者として開いたコマンドプロンプトで次を実行します。logman queryの公式仕様にある-etsは、保存されたデータコレクターセットではなくETWセッションを直接対象にする指定です。
logman query -etsエラーに出た名前と一覧を比較し、必要なら詳細を確認します。次の「実際のセッション名」は、イベントと一覧で確認した完全な名前へ置き換えます。
logman query "実際のセッション名" -ets一覧に同名があることは確認時点の状態です。イベント発生後に状態が変わる場合もあるため、名前が見つからないことだけで孤立したセッションとは判断できません。出力と確認時刻を保存します。
ETW セッション名に関する注意点
ETWのコントローラーがセッションと収集対象を管理します。Windowsやセキュリティ製品が使うセッションを、名前がエラーに出たという理由で停止しないでください。自作のトレースなら、所有者が開始・終了の重複を調べ、担当するセッションだけを管理します。
2. イベント全文と発生条件を保存
- Win＋Rでeventvwr.mscを開き、該当するKernel-EventTracingイベントを選ぶ。
- ［全般］の全文と［詳細］のXML表示を保存し、イベントID・コード・セッション名・日時を確認する。
- 起動直後、サインイン時、特定アプリの開始時など、繰り返す条件を記録する。
- 同じ時刻に起きた症状があれば、内容と関連ログも記録する。
このコードだけを理由にWMIサービスを再起動する必要があるとは判断できません。管理や監視で使うサービスを一律に止めるより、開始処理を担当する製品や管理者へ記録を渡します。
3. ログを消さず、必要なイベントをエクスポート
wevtutilの公式仕様では、eplはイベントのエクスポート、clはイベント記録の消去です。イベントログを消去しても、ETWセッションを停止・削除する操作にはなりません。調査の前に消すと発生状況の証拠を失います。
イベントビューアーで対象のログを選び、必要なイベントを保存して管理者へ渡します。コマンドを使う場合は、wevtutil elで対象PCの実際のログ名を確認したうえで、wevtutil epl "ログ名" "保存先のevtxファイル"を使います。ログ名と保存先は対象環境の値へ置き換え、既存ファイルに上書きしない保存先を選びます。
wevtutil el「Operational」などのチャネル名を推測して削除する手順や、AutoLoggerのレジストリ設定を一括で無効にする手順は実行しません。製品の既知問題や自作トレースの修正を確認してから、必要な変更を担当者が行います。
4. ドライバーの更新
実際のデバイス不調や警告がある場合は、そのデバイスに合うドライバーの更新情報を確認します。デバイス マネージャーやハードウェア ベンダーの公式サポートで、PCの機種・OS・対象デバイスを照合します。0xC0000035だけでセンサーのドライバーが原因とは判断しません。
- デバイス マネージャーからの確認
「センサー」や「システム デバイス」などの項目を調べ、警告アイコン（黄色の三角形）が表示されていないか確認。 - ベンダー配布サイトからのドライバー取得
Microsoft Update カタログだけでなく、ハードウェア ベンダーが独自に提供しているドライバーが存在する場合があります。サーバーベンダー、デバイスベンダーの公式サイトを定期的に確認することもポイントです。
5. 自分が管理する収集タスクの重複を確認
組織や自分で設定したトレース収集がある場合は、同じ処理が手動・定期実行・複数スクリプトから重なって開始されていないかを担当者が確認します。StartTrace仕様は、コンポーネント自身のセッションが既に動いている場合、別の名前を次々に作るのではなく、そのコンポーネントの既存セッションを適切に扱うよう求めています。
Microsoft配下のタスクや監視ポリシーを、関連しそうな名前という理由で無効化しないでください。管理対象の収集設定について、開始元・実行時刻・終了処理を確認し、変更は一つずつ行って再発条件を比べます。
6. イベント ビューアーで追加情報を確認
Kernel-EventTracing のイベントログだけでなく、「Applications and Services Logs」→「Microsoft」→「Windows」フォルダ以下に詳細ログが記録されている場合があります。複数のイベントログを横断的に見ていると、以下のような追加ヒントが得られることがあります。
- 同時刻に発生している警告やエラー
直前・直後の別のイベントも記録します。同時刻であるだけでは原因と決めず、実際の症状と照合します。 - 依存関係のあるサービスのエラーログ
実際に症状が出ているアプリやサービスのログを確認します。名前だけで関連性を決めません。 - OSのビルド番号や更新履歴
イベントログのシステム情報を確認して、直近でパッチ適用やバージョンアップが行われていないかをチェック。
調査手順と変更する範囲のまとめ
| 順番 | 確認すること | 次の判断 |
|---|---|---|
| 1 | イベント全文・セッション名・日時・症状 | イベントだけか、実際の支障もあるかを分ける |
| 2 | logman query -etsの一覧と詳細 | 現在の同名セッションと発生時刻の記録を比較する |
| 3 | イベント記録の保存・エクスポート | 消去せず担当者へ渡す |
| 4 | 関連アプリ・デバイスの症状と更新履歴 | 対象製品の修正情報を確認する |
| 5 | 管理している収集処理の開始・終了 | 所有者が重複開始を修正して再発を確認する |
よくある質問 (FAQ)
Q1. エラーが出続けるが、サーバーに特に不具合が見られない場合は放置してもいい？
A1. イベントだけで重大障害の前兆とも無害とも断定できません。発生回数・日時・更新履歴を残し、症状がなければ監視を続け、増加や実際の支障があれば管理者へ相談します。ログを消すことを解決の基準にしません。
Q2. 「SensorFramework-○○○」というセッション名が消せない場合、強制的に削除しても大丈夫？
A2. エラーに名前が出たことだけを理由に強制削除しません。誰が何のために管理しているセッションかを確認します。自作トレースの所有者による終了処理の修正と、OS・製品側のセッションを利用者が停止することは分けて考えます。
Q3. ドライバーを更新してもエラーが解消しないのはなぜ？
A3. ドライバーが原因と確定していない場合、更新しても開始失敗が変わらないことがあります。元のイベント全文・名前・発生条件へ戻り、関連する製品や自作収集処理を調べます。WMI再起動やログ消去を続けるのではなく、記録を担当者へ渡してください。
解決しない場合に管理者・サポートへ渡す情報
Windowsのエディション・ビルド、イベント全文と保存したログ、発生時刻、実際の症状、直前の変更と実施した確認をまとめます。特定製品の起動時だけに出る場合はその製品のサポート、組織のPCではIT管理者へ相談します。0xC0000035の表示だけを理由にOSを再インストールする必要があるとは判断できません。
まとめ：名前の重複と実際の症状を分けて調べる
Kernel-EventTracingのイベントID 2と0xC0000035では、名前の重複を手掛かりに、イベント全文と現在のETWセッションを読み取りで確認します。MPWppUpdateLoggingやPerfDiag Loggerなどの名前が違っても、停止・レジストリ変更・ログ消去を一律に実行しません。記録と発生条件を残し、対象の収集処理を管理する担当者と確認を進めます。
コメント