問題タブ [etw]

現在、ETW トレース機能を介して NT Kernel Logger を使用するアプリケーションを作成しています。リアルタイムモードで消費します。Windows 7 テスト マシンでは問題なく動作しますが、XP VM では定期的にメモリ不足の例外が発生していました。

APIMonitor (素晴らしいツール) を使用して、ProcessTrace() Win32 API 呼び出し自体を使用した NtAllocateVirtualMemory() への呼び出しまで追跡しました。スクリーンショットでわかるように、1GB の連続したメモリを割り当てようとしています。

誰もこれに遭遇したことがありますか？なぜそんなに多くのメモリを割り当てる必要があるのか​​ わかりません。さらに、文書化されていない Win32 API 関数 (WmiMofEnumerateResourcesA()) の ProcessTrace() コール スタックの奥深くで呼び出しが発生しているため、実際に影響を与えることはできないようです。誰もこれに遭遇したことがありますか？潜在的な解決策をいただければ幸いです。

XP/2003 をサポートする必要がありますが、32 ビット バージョンでは、1 GB の連続したメモリが利用できるとは本当に想定できません。リアルタイム処理も必要です。ただし、可能であれば、.ETL ファイルに追加された新しいイベントを「リアルタイム」で処理するなど、イベントの損失を伴わないファイル ベースのログ記録を使用する回避策を検討できます。

マニフェスト ベースの ETW ソリューションを使用したい C/C++ アプリがあります。生成された *.etl (Windows のデフォルトのものなど) を開くツールを使用すると、イベントの特定の詳細 (マニフェストで定義されたテンプレート) が表示されないという問題があります。

マニフェストをシステムに登録し、よく知られている ETW コンシューマー ツールに指定してその情報を表示するにはどうすればよいですか?

http://www.codeproject.com/Articles/570690/Application-Analysis-with-Event-Tracing-for-Windowに記載されていることを行いました

また、マニフェストを次のように登録しました。

何か案は ？

マイクロソフト フォーラムでこの質問をしたところ、彼らの行動に驚きました。

これは質問ですhttp://social.msdn.microsoft.com/Forums/en-US/windowsgeneraldevelopmentissues/thread/6c2354ae-f9f6-423f-bf91-a34b40e20fa1 :

また、いくつかの詳細情報とともにここに再投稿しました。

This post Problem installation WPT manifest using wevtutil は、wevtutil がマニフェストの resourcefileName 属性のサイズに制限があることを示唆しています。

これはいけないと思っていたのですが、残念ながらそうです！

なぜこのような制限が必要なのか不思議です。

これが私がやったことです。パスの深さがかなり中程度のソリューションがあります (例: C:\users\\\

イベント トレースの設定に必要なマニフェスト ファイル内の resourceFileName と messageFileName をポイントすると、こちらを参照してください: http://msdn.microsoft.com/en-us/library/windows/desktop/dd996930(v=vs .85).aspx) を元のパス (上記の形式) の exe に追加すると、次の警告が表示されます。

exe のパスを C:\temp\publisher.exe のようなものに設定し、手動でコピーすると

exe をソリューション出力ディレクトリから C:\temp フォルダーに移動すると、すべて正常に動作します。

PS: また、exe にはアクセシビリティのための適切な権限が必要です。

さて、私の質問は、ファイル パスに対するこの不必要な制限はなぜですか? このおそらく強力な API が、特定の長さを超えるファイルパスを処理できないように記述されている場合、プログラムが非常に貧弱であると言って申し訳ありません。皮肉なことに、アプリケーションで使用したい機能がたくさんあります。そうは言っても、この動作を変更できる resourceFileName および messageFileName 属性の特定のオプションはありますか? msdn はそれについて何も言いません。または、何か不足していますか？

まず、任意のパスからイベント パブリッシャーをインストールするための回避策を誰かが見つけた場合は、教えていただけますか?

次に、Microsoft の対応です。私の質問をきちんと読まないまま、司会者が私の質問を Windows Server スレッドに移動しました (彼は、明らかに Windows Server と何らかの関係があると思われる resourceFileName という単語でこれを推測しました)。

EventSourceクラスを使用して ETW イベントを発行するように .NET 4.5 アプリケーションをインストルメント化しています。目標は、エラー ログ用にこれらのイベント (エラー レベル イベント) の一部をキャプチャできるようにすることです。

いくつかの読み取りとテストを行った後、エラーログへのこのアプローチの信頼性、特にイベントのドロップまたは欠落の可能性について懸念しています。エラー ログが機能しない場合は、アプリケーションをシャットダウンする必要があります (私の場合、報告されていないエラーで実行するのは安全ではありません)。ETW と を使用しEventSourceている場合、エラーが適切に記録されていることを確認するにはどうすればよいですか?

明らかに、答えの一部は、何がイベントをリッスンしているかによって異なります。私の場合、最新の MS Enterprise Library の「Semantic Logging Application Block」を使用する予定です。

以下は、Microsoft が見逃したイベントの考えられる原因について話しているソースの 1 つです。 イベント トレーシングについて

そこには、欠落イベントの考えられる原因がリストされています

• イベントの合計サイズが 64K を超えています。これには、ETW ヘッダーとデータまたはペイロードが含まれます。イベントのサイズはアプリケーションによって設定されるため、ユーザーはこれらの欠落したイベントを制御することはできません。

• ETW バッファー サイズが合計イベント サイズよりも小さい。イベントのサイズはイベントをログに記録するアプリケーションによって設定されるため、ユーザーはこれらの欠落したイベントを制御することはできません。

• リアルタイム ログの場合、リアルタイム コンシューマーがイベントを十分に高速に消費していないか、完全に存在しないため、バッキング ファイルがいっぱいになります。これは、イベントがログに記録されているときにイベント ログ サービスが停止され、開始された場合に発生する可能性があります。ユーザーは、これらの欠落したイベントを制御できません。

• ファイルにログを記録するとき、ディスクが遅すぎてログ速度に追いつけません。

これらの懸念が EventSource クラスを使用して何らかの方法で緩和されたかどうか (たとえば、大きなペイロードを何らかの方法で切り捨てるかどうか) を確認するために、いくつかのテストを行いました。長い文字列をログに記録しようとしましたが、30,000 から 35,000 文字の間で失敗しました (64KB の最大イベント ペイロードと一致しています)。大きすぎる文字列について私が知ることができることから、黙って何もしません。セマンティック ログのアプリケーション ブロック ログにイベントはまったくありません。前後の出来事はいつものように書かれています。

ペイロードに文字列があるときはいつでも、トランケータを介して渡す必要がありますか? 「速すぎる」イベントの生成を手動で回避する必要がありますか (また、それはどのように可能でしょうか)。

Microsoft のパターンとプラクティスは、私たちを適切なパターンとプラクティスに導くはずなので、ここで何かが欠けているだけかもしれません。

アップデート：

どうやら、「イベントが速すぎる」状態について、消費アプリケーションに何らかの通知があるようです。今日初めてこれを受け取りました：

レベル: 警告、メッセージ: トレース セッションでのバッファー オーバーランまたはスキーマ同期の遅延により、一部のイベントが失われます: Microsoft-SemanticLogging-Etw-svcRuntime

そして、セッションを閉じるとき：

レベル: 警告、メッセージ: トレース セッション 'Microsoft-SemanticLogging-Etw-svcRuntime' で 1 つのイベントの損失が検出されました。

アップデート2:

Enterprise Library Developers Guideでは、先ほど説明した動作について説明しています。

セマンティック ログ アプリケーション ブロックによって生成されたログ メッセージを監視して、バッファがオーバーフローしたことやメッセージが失われたことを示す兆候がないかどうかを確認する必要があります。たとえば、イベント ID 900 および 901 のログ メッセージは、シンクの内部バッファがオーバーフローしたことを示します。アウト プロセス シナリオでは、イベント ID 806 および 807 は、ETW バッファーがオーバーフローしたことを示します。シンクのバッファリング構成オプションを変更して、通常のワークロードでバッファがオーバーフローする可能性を減らすことができます。

エラーがドロップされた場合にアプリケーションが実行されないようにしながら、セマンティック ロギングを使用できますか? 通常のトレース イベントがドロップされる可能性があります ...

私の現在の考えでは、昔ながらのロギング手法を使用して別のクラスで「重大な」エラーをログに記録し、重大度の低いエラー (およびデバッグ タイプのイベント) は ETW パイプラインを通過するようにします。それはそれほど悪くはありません...より良い提案が見つからない場合は、解決策として投稿するかもしれません.

更新 3:

string私が受け取った「missing events」という警告は、バッファ オーバーランとは何の関係もありませんでした。これは、ペイロード値としてnull を渡した場合に表示されるメッセージであることがわかりました。

.net 4.5 で ETW を使用しようとしています。

WCF サービスとコンソール アプリがあり、EventSource を使用してメッセージを書き込む必要がありますが、ファイル (ローリング ファイル) にログを記録するための独自の ETW (EventSource と EventListener) を作成する方法を理解するのに苦労しています。

助言がありますか？

Windows ドライバーの内部から、次の方法を知りたいです。

a）特定の組み込みプロバイダーを有効にする

b）ドライバーの一部であるコールバック関数（何かをしたい場所）を提供することにより、イベントをリアルタイムで消費します。

c) プロバイダーをオフにします。

PS: 「オンにする」と「オフにする」という言葉を大まかに使用しました。Windows ETW の用語では、プロバイダーを "有効にする" と呼ばれていると思います。

これまでのところ、これを行う方法に関する情報をウェブで検索してきましたが、まだ何も見つかりませんでした。

リクエスト URL を含む IIS または ASP.NET によって作成された ETW イベントをキャプチャしようとしましたが、あまり成功しませんでした。

Windows 8 (開発) と Windows Server 2008 R2 (運用) を使用しているため、それぞれ IIS 8.0 と 7.5 です。IIS 8.5 ではより優れた ETW サポートがあることは認識していますが、残念ながら現時点では役に立ちません。

PerfViewを使用してシステム全体のイベントを収集し、次の追加プロバイダーMicrosoft-Windows-IIS-Configurationを使用して、名前空間でいくつかのイベントを取得しますが、個々の要求の詳細を含むものは何も取得しません。

追加のプロバイダー

実行するlogman query providersと、次の結果が得られるので、これらのプロバイダーが (私の Windows 8 マシンで) 利用可能であることがわかります。

また、logman を使用して ETL ファイルを作成しようとしましたが、これは IIS 関連のものをキャプチャしていないようです:

etw.ps1

プロバイダー.txt

0xFFFFFFFEとで上記を試しました0xFFFFFFFF。

現在、システムのログを置き換えることを調査しています。多くの場所で、イベント ソースが存在しない場合にイベント ソースを自動作成する通常の EventLog API を既に使用しています。

通常の EventLog API (非常に使いやすい) を使用する代わりに、適切な EventSources を使用するようにコードを変換することの利点を知りたいと思います。これはやる価値がありますか？

ロギング (単一の成功/エラー/情報/警告ステータス イベントについて知りたい場合) とトレースの両方を実現したいと考えています。