次の方法で共有

WNODE_HEADER構造体

  • [アーティクル]

WNODE_HEADER構造体は、EVENT_TRACE_PROPERTIES構造体のメンバーです。

構文

typedef struct _WNODE_HEADER {
  ULONG BufferSize;
  ULONG ProviderId;
  union {
    ULONG64 HistoricalContext;
    struct {
      ULONG Version;
      ULONG Linkage;
    };
  };
  union {
    HANDLE        KernelHandle;
    LARGE_INTEGER TimeStamp;
  };
  GUID  Guid;
  ULONG ClientContext;
  ULONG Flags;
} WNODE_HEADER, *PWNODE_HEADER;

メンバー

BufferSize

イベント トレース セッションのプロパティに割り当てられたメモリの合計サイズ (バイト単位)。 メモリのサイズには、 EVENT_TRACE_PROPERTIES 構造体のスペースに、メモリ内の構造体に続くセッション名文字列とログ ファイル名文字列を含める必要があります。

ProviderId

内部使用のために予約されています。

HistoricalContext

出力時に、イベント トレース セッションへのハンドル。

Version

内部使用のために予約されています。

リンケージ

内部使用のために予約されています。

KernelHandle

内部使用のために予約されています。

タイムスタンプ

1601 年 1 月 1 日午前 0 時から 100 ナノ秒間隔で、この構造体の情報が更新された時刻。

Guid

セッションに対して定義する GUID。

NT カーネル ロガー セッションの場合は、このメンバーを SystemTraceControlGuid に設定します。

このメンバーが SystemTraceControlGuid または GlobalLoggerGuid に設定されている場合、ロガーはシステム ロガーになります。

プライベート ロガー セッションの場合は、このメンバーを、セッションに対して有効にするプロバイダーの GUID に設定します。

カーネル ロガーまたはプライベート ロガー セッションではないセッションを開始する場合は、セッション GUID を指定する必要はありません。 GUID を指定しない場合、ETW によって自動的に作成されます。 セッション GUID は、特定のセッションに関連付けられている既定のアクセス許可を変更する場合にのみ指定する必要があります。 詳細については、EventAccessControl 関数を参照してください。

同じセッション GUID を使用して複数のセッションを開始することはできません。

Windows Vista より前: 同じセッション GUID を使用して、複数のセッションを開始できます。

ClientContext

各イベントのタイム スタンプをログに記録するときに使用するクロック解像度。 既定値は Query パフォーマンス カウンター (QPC) です。

Windows Vista より前: 既定値はシステム時刻です。

Windows 10より前のバージョン 1703: どのシステム ロガーでも同時に使用できる個別のクロックの種類は 2 つまでです。

Windows 10 バージョン 1703 以降: クロックの種類の制限が削除されました。 3 種類のクロックはすべて、システム ロガーで同時に使用できるようになりました。

次のいずれかの値を指定できます。

値 説明
1
 クエリ パフォーマンス カウンター (QPC)。 QPC カウンターは、システム クロックの調整の影響を受けず、高解像度のタイムスタンプを提供します。 イベントに格納されているタイム スタンプは、QueryPerformanceCounter API から返される値と同じです。 このタイム スタンプの特性の詳細については、「高解像度タイム スタンプの 取得」を参照してください。
この解決は、イベントレートが高い場合、またはコンシューマーが異なるバッファーのイベントをマージする場合に使用する必要があります。 このような場合、QPC タイム スタンプの精度と安定性により、さまざまなバッファーからイベントを並べ替える精度が向上します。 ただし、トレースの進行中に NTP サーバーとの同期が原因でシステム クロックが前方に調整された場合など、QPC タイム スタンプはシステム クロックの更新を反映しません。トレース内の QPC タイム スタンプは、更新が行われていないかのように時間を反映し続けます。
解決を決定するには、イベントの使用時に TRACE_LOGFILE_HEADER の PerfFreq メンバーを使用します。
イベントのタイムスタンプを 100 ns 単位に変換するには、次の変換式を使用します。
scaledTimestamp = eventRecord.EventHeader.TimeStamp.QuadPart * 10000000.0 / logfileHeader.PerfFreq.QuadPart
古いコンピューターでは、ハードウェア エラーが原因でカウンターが前方にスキップする場合があるため、タイムスタンプが正確でない場合があることに注意してください。
2
 システム時刻。 システム時刻には、システムのクロックへの変更を追跡するタイム スタンプが用意されています。たとえば、トレースの進行中に NTP サーバーとの同期が原因でシステム クロックが前方に調整されている場合、トレース内のシステム タイム スタンプもシステム クロックの新しい設定に合わせて前方にジャンプします。
  • Windows 10より前のシステムでは、イベントに格納されているタイム スタンプは、GetSystemTimeAsFileTime API から返される値と同じです。
  • Windows 10 以降では、イベントに格納されているタイム スタンプは、GetSystemTimePreciseAsFileTime API から返される値と同じです。
Windows 10より前の時点では、このタイムスタンプの解像度は、TRACE_LOGFILE_HEADERの TimerResolution メンバーによって示されるように、システム クロック ティックの解像度でした。 Windows 10以降、このタイム スタンプの解像度は、TRACE_LOGFILE_HEADER の PerfFreq メンバーによって示されるパフォーマンス カウンターの解像度です。
イベントのタイムスタンプを 100 ns 単位に変換するには、次の変換式を使用します。
scaledTimestamp = eventRecord.EventHeader.TimeStamp.QuadPart
Windows 10する前に OS を実行しているシステムでイベントがキャプチャされる場合、イベントの量が多い場合、システム時間の解像度が十分でない可能性があり、イベントのシーケンスを決定するのに十分ではありません。 この場合、一連のイベントのタイム スタンプは同じですが、ETW がイベントを配信する順序が正しくありません。 Windows 10以降、タイム スタンプは追加の精度でキャプチャされますが、トレースのキャプチャ中にシステム クロックが調整された場合でも、不安定な状態が発生する可能性があります。
3
 CPU サイクル カウンター。 CPU カウンターは、最も高い解像度のタイム スタンプを提供し、取得するリソースの消費量が最も少ありません。 ただし、CPU カウンターは信頼できず、実稼働環境では使用できません。 たとえば、一部のコンピューターでは、一部の状態で停止するだけでなく、温度と電力の変化によってタイマーの頻度が変更されます。
解決を決定するには、イベントの使用時に TRACE_LOGFILE_HEADER の CpuSpeedInMHz メンバーを使用します。
ハードウェアでこのクロックの種類がサポートされていない場合、ETW ではシステム時刻が使用されます。
Windows Server 2003、Windows XP SP1 および Windows XP: この値はサポートされていません。これは、Windows Server 2003 SP1 と Windows XP SP2 で導入されました。

 

Windows 2000:ClientContext メンバーはサポートされていません。

Flags

構造体にイベント トレース情報が含まれていることを示すには、 WNODE_FLAG_TRACED_GUID を含める必要があります。

解説

メンバーを設定する前に、必ずこの構造体のメモリを 0 に初期化してください。

ETW タイムスタンプを FILETIME に変換するには、次の手順に従います。

1. 処理されるセッションまたはログ ファイルごとに (つまり、EVENT\_TRACE\_LOGFILEごとに)、logFile.ProcessTraceMode フィールドをチェックして、PROCESS\_TRACE\_MODE\_RAW\_TIMESTAMP フラグが設定されているかどうかを確認します。 既定では、このフラグは設定されていません。 このフラグが設定されていない場合、ETW ランタイムは EVENT\_RECORD を EventRecordCallback 関数に送信する前に、各 EVENT\_RECORD のタイムスタンプを FILETIME に自動的に変換するため、追加の処理は必要ありません。 次の手順は、PROCESS\_TRACE\_MODE\_RAW\_TIMESTAMP フラグが設定された状態でトレースが処理されている場合にのみ使用する必要があります。 2. 処理されるセッションまたはログ ファイルごとに (つまり、EVENT\_TRACE\_LOGFILE ごとに)、logFile.LogfileHeader.ReservedFlags フィールドをチェックして、ログ ファイルのタイム スタンプ スケールを決定します。 ReservedFlags の値に基づいて、次のいずれかの手順に従って、残りの手順で timeStampScale に使用する値を決定します。
a。 ReservedFlags == 1 (QPC): DOUBLE timeStampScale = 10000000.0 / logFile.LogfileHeader.PerfFreq.QuadPart;B。 ReservedFlags == 2 (システム時間): DOUBLE timeStampScale = 1.0;イベントは既に FILETIME 単位でタイムスタンプを提供しているため、システム時刻を使用するイベントでは残りの手順は不要であることに注意してください。 残りの手順は機能しますが、不要であり、小さな丸めエラーが発生します。 c. ReservedFlags == 3 (CPU サイクル カウンター) の場合: DOUBLE timeStampScale = 10.0 / logFile.LogfileHeader.CpuSpeedInMHz;
3. 特定のログ ファイルに対する EventRecordCallback 関数の最初の呼び出しで、 logFile (EVENT\_TRACE\_LOGFILE) と eventRecord (EVENT\_RECORD) のデータを使用して、ログ ファイル内の残りのイベントに使用される timeStampBase を計算します。INT64 timeStampBase = logFile.LogfileHeader.StartTime.QuadPart - (INT64)(timeStampScale \* eventRecord.EventHeader.TimeStamp.QuadPart);4. 各 eventRecord (EVENT\_RECORD) について、手順 2 および 3 で計算された timeStampScale 値と timeStampBase 値を使用して、次のようにイベントのタイムスタンプを FILETIME に変換します。INT64 timeStampInFileTime = timeStampBase + (INT64)(timeStampScale \* eventRecord.EventHeader.TimeStamp.QuadPart);

要件

要件 値
サポートされている最小のクライアント
 Windows 2000 Professional [デスクトップ アプリ |UWP アプリ]
サポートされている最小のサーバー
 Windows 2000 Server [デスクトップ アプリ |UWP アプリ]
ヘッダー
Wmistr.h

関連項目

ControlCallback

EVENT_TRACE_PROPERTIES

GetTraceLoggerHandle

LARGE_INTEGER