日々の運用の中で見慣れないエラーがイベントログに現れると、不安になってしまいますよね。特に、複数のサーバーで同じエラーが報告されると「何か大きな問題なのでは？」と焦ってしまう方も多いことでしょう。この記事では、Kernel-EventTracing (Event ID 2) における 0xC0000035 エラーについて、考えられる原因や具体的な対処方法を丁寧に解説していきます。原因の特定やログの調査方法を知っておくことで、運用トラブルにスムーズに対応できるようになるはずです。
Kernel-EventTracing イベントログ (Event ID 2) で発生する 0xC0000035エラーとは？
Kernel-EventTracing (Event ID 2) で報告される「Session “SensorFramework-xxxxxx” failed to start with the following error: 0xC0000035.」というエラーは、Windows Server やクライアントOSを問わず発生する可能性があります。0xC0000035 は STATUS_OBJECT_NAME_COLLISION と呼ばれるエラーコードであり、名前の重複により同名の ETW (Event Tracing for Windows) セッションがすでに存在していることが多くの原因です。ここでは、エラーの概略と背景を紐解きながら、具体的な解決アプローチを見ていきましょう。
0xC0000035 (STATUS_OBJECT_NAME_COLLISION) の意味
0xC0000035、つまり STATUS_OBJECT_NAME_COLLISION は、システム上のオブジェクト名が既に使用されている状態を示しています。ETW セッションにおいてもセッション名が競合していると、同じセッション名を新たに起動できず、結果としてこのエラーが発生します。実際には以下のようなケースが考えられます。
- 同名の ETW セッションを再起動しようとしたが、前のセッションが停止・クリーンアップされていない
- タスク スケジューラやグループ ポリシーなどで複数回同じセッションを起動するよう設定してしまっている
- センサー系ドライバーの不整合やバージョン問題により、同様のセッションを無制限に作成しようとして失敗
エラー発生の影響範囲
このエラーが出ていても、通常のシステム動作に大きな影響を及ぼさないケースが多いとされています。しかし、ログファイルの肥大化や、OSやドライバーが何かしらの不具合を抱えているシグナルである可能性も無視できません。特にサーバー環境では、わずかな問題も積み重なると想定外のダウンタイムにつながるリスクがあるため、早めの対処が重要です。
実運用で見逃しがちなポイント
運用管理者の方が見落としがちなポイントとして、イベントログは普段から監視していないと「必要になったときに急いで調べる」という場面が多いことが挙げられます。そのため、ひとたび Kernel-EventTracing のエラーが連続的に記録されるようになると「何が原因なのか把握できないまま放置されがち」という状況に陥りやすいのです。監視体制の強化や定期的なログチェック体制が望まれます。
よくある原因と対処策
以下では、0xC0000035 エラーが発生した際の対処策を細かく解説します。必要に応じて、すべてのステップを順番に実行するのが望ましいですが、状況や環境に合わせて実行可能なものから試してみてください。
1. 既存の ETW セッションの確認
ETW セッションの競合が疑われる場合、まずは現在動作しているセッションを確認することが肝心です。セッション名の競合を発見し、重複しているセッションを停止するだけで解決することも少なくありません。
@echo off
:: 管理者権限のコマンドプロンプトにて
logman query
:: 特定セッションを停止
logman stop "SensorFramework-{d61722cd-d3ce-0897-1694-d917cab88c2a}" -ets上記のように、logman query コマンドで現在稼働中のセッション一覧を取得し、停止させたいセッション名があれば logman stop <セッション名> -ets で明示的に停止できます。もしエラーで示されているセッション名が分かるなら、同じ名前を指定して停止してください。
ETW セッション名に関する注意点
- 「SensorFramework-xxxxxx」など、製品やドライバーが標準で作成する名前が存在する場合があります。勝手に削除してしまうと、センサー関連機能に不具合が生じる可能性もあるため注意が必要です。
- 同一セッションを停止しすぎると、今度は必要なログが取得できなくなる恐れもあるので、何が起動しているのか用途を確認した上で作業してください。
2. WMI サービスの再起動
Windows の管理・監視機能を統括する WMI (Windows Management Instrumentation) サービスを再起動すると、一部の ETW セッションがリセットされる場合があります。WMI サービスが不安定になり、セッションがクリーンに終了しないまま残ると、セッション名が衝突する原因となることがあります。
@echo off
net stop winmgmt
net start winmgmt管理者権限のコマンド プロンプト（または PowerShell）で上記を実行してください。サービスの再起動により、一時的に WMI を利用する管理系ツールや監視ツールが機能しなくなる可能性がありますので、タイミングや影響範囲を考慮して実施することが重要です。
WMI サービスの安定化を図るポイント
- 再起動後はエラーが繰り返し発生していないか、イベントログを少しの間モニタリングする
- 再起動スクリプトを定期的に実行するのではなく、根本原因を突き止めた上で都度対処する
- サーバー再起動が可能な場合は、OS再起動で広範囲にクリーンアップが行われるケースもある
3. 孤立したセッション (オーファン セッション) のクリーンアップ
ETW セッションの停止に失敗したり、OSやドライバーの不具合でセッションが孤立状態になっていることがあります。こうしたセッションを「オーファン セッション」と呼ぶことがあります。オーファン セッションは通常のコマンド（logman stop など）で制御できない場合があり、イベントログ自体をクリアする、あるいはシステム設定ファイルを直接編集して削除するなど強制的な対応が必要です。
下記のように、wevtutil を使って該当セッションをクリアする方法があります。
@echo off
:: イベントログのリストを表示
wevtutil el
:: 特定のログ名を指定してクリア
wevtutil cl "Microsoft-Windows-Kernel-EventTracing/Operational"セッション名やログ名を指定して不要なものだけをクリアするのが望ましいですが、誤って必要なログをクリアしてしまうと、重要な情報を失うリスクがあります。バックアップを取ったうえで実行することを強くおすすめします。
オーファン セッションを特定するためのヒント
- まず
logman queryで表示されないセッションでも、イベントビューアにだけ痕跡がある場合は、オーファン化を疑う - イベントログ内の “Session Start” 系メッセージと “Session Stop” 系メッセージをチェックし、開始のみで停止がないセッションを探す
- Windows Update 後やドライバー更新直後に発生する場合は、アップデート プロセスがセッションをクリーンに終了していない可能性が高い
4. ドライバーの更新
センサー関連のドライバーが古い、または Windows Server やクライアントOSのバージョンに適合しないバージョンを使っていると、ETW セッションの制御がうまくいかず、エラーが発生する可能性があります。デバイス マネージャーや Windows Update カタログ、ベンダーのサポート ページなどで最新のドライバーを確認し、必要に応じて更新するのがおすすめです。
- デバイス マネージャーからの確認
「センサー」や「システム デバイス」などの項目を調べ、警告アイコン（黄色の三角形）が表示されていないか確認。 - ベンダー配布サイトからのドライバー取得
Microsoft Update カタログだけでなく、ハードウェア ベンダーが独自に提供しているドライバーが存在する場合があります。サーバーベンダー、デバイスベンダーの公式サイトを定期的に確認することもポイントです。
5. グループ ポリシーやタスク スケジューラの設定確認
思わぬところに落とし穴があるのが、グループ ポリシー (GPO) やタスク スケジューラの設定です。ログ収集や監視系のポリシー、またはタスクが誤って重複する ETW セッションを起動し続けている場合があります。
- グループ ポリシー エディタ (gpedit.msc)
管理用テンプレートやログ記録に関する設定を見直し、ETW トレースを強制的に有効化する設定がないか探る。 - タスク スケジューラ (taskschd.msc)
「Microsoft」「Windows」「Tracing」などのフォルダ配下で、SensorFramework 系やドライバー関連のタスクが無限ループしていないかチェックする。特定のトリガーが誤って日常的にセッションを追加起動している可能性も。
6. イベント ビューアーで追加情報を確認
Kernel-EventTracing のイベントログだけでなく、「Applications and Services Logs」→「Microsoft」→「Windows」フォルダ以下に詳細ログが記録されている場合があります。複数のイベントログを横断的に見ていると、以下のような追加ヒントが得られることがあります。
- 同時刻に発生している警告やエラー
ETW セッション関連のエラーが起こる直前・直後に別のサービスがエラーを報告しているケースも多い。そこから根本原因が分かる場合がある。 - 依存関係のあるサービスのエラーログ
WMI、Windows Update、Sensor 関連サービスなどにエラーログが残っていれば、それが原因となっている可能性大。 - OSのビルド番号や更新履歴
イベントログのシステム情報を確認して、直近でパッチ適用やバージョンアップが行われていないかをチェック。
具体的な解決手順のまとめ
ここまでの内容を整理するために、主な対処手順を表にしてまとめました。トラブルシューティングの際に役立ててみてください。
| 手順 | 内容 | 実行コマンド例 | 補足 |
|---|---|---|---|
| 1. ETW セッションの確認 | 現在稼働中のセッションを確認し、衝突がないか見る | logman query | 不要なセッション名を把握したらlogman stop で停止 |
| 2. WMI サービスの再起動 | WMI が正常に動作しているか確認し、再起動 | net stop winmgmt<br>net start winmgmt | 実行中に WMI を用いるツールが動作停止する可能性があるため、時間に注意 |
| 3. オーファン セッション削除 | wevtutil を使って不要ログを削除 | wevtutil el<br>wevtutil cl "ログ名" | バックアップを取った上で実行し、必要なログを誤って削除しないように注意 |
| 4. ドライバー更新 | センサー関連ドライバーやシステムドライバーの更新 | （デバイス マネージャーやベンダーサイトを参照） | 古いドライバーだと ETW セッションを正しく扱えないケースがある |
| 5. GPO/タスク スケジューラ確認 | グループ ポリシーやタスクで重複セッション起動を防ぐ | gpedit.msc / taskschd.msc | 不要なタスクや設定を無効化する |
| 6. 詳細イベントログ確認 | 関連サービスやドライバーがエラーを出していないか調査 | eventvwr.msc | 複合的な原因を突き止めるために、複数のログを併せて参照する |
よくある質問 (FAQ)
Q1. エラーが出続けるが、サーバーに特に不具合が見られない場合は放置してもいい？
A1. 一見問題がなさそうに見えても、将来的にパフォーマンス低下やログ肥大化などの悪影響が出る可能性があります。重大障害の前兆というケースも否定できません。イベントログを整理し、エラーの原因を明確にしておくことをおすすめします。
Q2. 「SensorFramework-○○○」というセッション名が消せない場合、強制的に削除しても大丈夫？
A2. 必要なセンサー機能やドライバーが利用するセッションである可能性があるため、まずはそのセッションが本当に不要かを見極めることが先決です。もし誤って消すとセンサー機能が動作しなくなるリスクもあります。削除する前にシステムやドライバーの稼働状況を確認しましょう。
Q3. ドライバーを更新してもエラーが解消しないのはなぜ？
A3. 原因がドライバー以外にある場合、セッションのクリーンアップやポリシーの見直しなど、他のステップを併せて行う必要があります。特に、グループ ポリシーやタスク スケジューラで重複起動の設定がされていないかを確認してください。
トラブルが解決しない場合の最終手段
上記の対処法を試してもエラーが解決しない場合、考慮すべき追加のアクションがあります。
- OS の再インストールやアップグレード
極端な方法ではありますが、OS が破損している可能性がある場合にはクリーン インストールを検討する。 - Microsoft サポートへの問い合わせ
公式のサポート プロフェッショナルが、ログ解析ツールなどを用いて問題を特定してくれる。サポート契約や有料のケースもあるが、大規模システムでは安心感が大きい。 - ベンダー問い合わせ
センサーやドライバーを提供しているベンダーの製品サポートを利用し、既知の不具合や修正プログラムがないか確認する。
まとめ：早めの対処で大きなトラブルを防ぐ
Kernel-EventTracing (Event ID 2) で 0xC0000035 エラーが表示される原因は、ETW セッション名の競合が大きな要因となっています。セッションのクリーンアップ、WMI サービスの再起動、不要タスクの停止など、やや地道な作業が必要ですが、その分確実に原因を取り除くことができます。何度も同じエラーが出る場合はドライバー更新やポリシー設定など、複数の観点からアプローチするのがポイントです。
ちょっとしたエラーログだからと軽視せず、早めに対応しておくことで将来的なトラブルを未然に防ぐことにつながります。サーバー環境においては些細なログの異常から重大なインシデントに波及するケースもあるので、こまめなメンテナンスと監視体制の整備が何よりも大切です。この記事が、運用やトラブルシューティングの一助になれば幸いです。
コメント