Erstellen einer Interessenbereichsdatei

Eine ROI Datei ist eine gültige XML Datei, die folgende Knoten enthält:

• Instrumentierungsmanifest

• Instrumentation

• Regionen

• RegionsRoot, ein Container für alle festgelegten Regionen

• Ein oder mehrere Regionen-Knoten

Hinweis

In der Definition einer Region ist das Attribut Version in der XML-Deklaration, wie z.B. version='1.0', optional.

Das folgende Beispiel zeigt eine vollständige Regions of Interest-Datei, die eine einfache Region definiert. Erläuterungen für die Attribute und Knoten innerhalb der Region werden im Anschluss an das Beispiel beschrieben.

<?xml version='1.0' encoding='utf-8' standalone='yes'?>
<?Copyright (c) Microsoft Corporation. All rights reserved.?>
<InstrumentationManifest>
   <Instrumentation>
      <Regions>
         <RegionRoot Guid="{EFA7A927-BAE3-48F6-92E1-000000000000}"
                     Name="Sample Region File Root"
                     FriendlyName="Root">
            <Region Guid="{d8d639a0-cf4c-45fb-976a-000111000100}"
                    Name="FastStartup-Suspend-UserSession-Shutdown"
                    FriendlyName="User Session Shutdown">
               <Start>
                  <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="301" Version="0" />
               </Start>
               <Stop>
                  <Event Provider="{331c3b3a-2005-44c2-ac5e-77220c37d6b4}" Id="22" Version="0" />
               </Stop>
            </Region>
         </RegionRoot>
      </Regions>
   </Instrumentation>
</InstrumentationManifest>

Definieren einer Region

Die Definition einer Region enthält die folgenden Attribute im Knoten Region :

• Guid (erforderlich), eine GUID für die Region.

• Name (erforderlich), ein eindeutiger Name für die Region. Ein empfohlenes Format für Name ist Root-GrandparentName-ParentName-RegionName.

• FriendlyName (optional), ein alternativer Name für die Region.

Regionsarten

Sie können die folgenden Regionsarten je nach deren Anfang und Ende erstellen:

• Regionen auf Basis von Ereignissen
• Regionen auf Basis der Dauer
• Regionen auf Basis anderer Regionen
• Regionen, die Container für andere Regionen bilden

Regionen auf Basis von Ereignissen

Der häufigste Bereichstyp ist ein Bereich, dessen Start- und Endpunkte durch Ereignisse definiert sind.

Um ein Ereignis als Start- oder Endpunkt zu definieren, müssen Sie die folgenden Attribute bereitstellen:

• Provider, eine GUID, die die Anbieter-ID für das Ereignis definiert.

• Id, eine nicht signierte Abkürzung, die die ID des Ereignisses definiert.

• Version, ein nicht signiertes Zeichen, das die Ereignisversion definiert.

Darüber hinaus können Sie Ihre Definition weiter einschränken, indem Sie mindestens einen PayloadIdentifier-Knoten hinzufügen. Diese Tags enthalten zwei Attribute von Zeichenfolgen, FieldName und FieldValue, die ein Feld definieren, das im Ereignis enthalten sein muss. Eine genauere Beschreibung von PayloadIdentifier-Tags finden Sie weiter unten unter Verwendung von Nutzlastfeldern zur Identifizierung von Ereignissen.

Beispiele

Nachstehend folgt ein grundlegendes Beispiel für diesen Bereichstyp:

<Region Guid="{d8d639a0-cf4c-45fb-976a-000111000100}"
        Name="FastStartup-Suspend-UserSession-Shutdown"
        FriendlyName="User Session Shutdown">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="301" Version="0" />
   </Start>
   <Stop>
      <Event Provider="{331c3b3a-2005-44c2-ac5e-77220c37d6b4}" Id="22" Version="0" />
   </Stop>
</Region>

Im folgenden Beispiel endet der Bereich nur, wenn das angegebene Ereignis ein Feld mit dem Namen StartOrStopmit einem Wert vonStop beinhaltet:

<Region Guid="{d8d639a0-cf4c-45fb-976a-000111000100}"
        Name="FastStartup-Suspend-UserSession-Shutdown"
        FriendlyName="User Session Shutdown">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="301" Version="0" />
   </Start>
   <Stop>
      <Event Provider="{331c3b3a-2005-44c2-ac5e-77220c37d6b4}" Id="22" Version="0" />
      <PayloadIdentifier FieldName="StartOrStop" FieldValue="Stop" />
   </Stop>
</Region>

Regionen auf Basis der Dauer

Viele ETW-Ereignisse werden als einzelnes Endereignis mit einem Dauernutzlastfeld definiert. Der Startpunkt kann berechnet werden, indem man die Dauer von der Endereigniszeit abzieht.

Das Tag Dauer kann innerhalb eines Start- oder Stopp-Tags verwendet werden, um ein Nutzlastfeld zu definieren, aus dem Dauerinformationen abgerufen werden sollen. Wenn Sie eine Dauer für den Startpunkt definieren, wird die Dauer vom Endpunkt abgezogen. Ebenso wird, wenn Sie eine Dauer für den Endpunkt definieren, die Dauer zum Startpunkt hinzugerechnet.

Der Knoten Dauer kann die folgenden Attribute aufweisen:

• Provider, eine GUID, die die Anbieter-ID für das Ereignis definiert, in dem das Nutzlastfeld enthalten ist.

• Id, eine nicht signierte Abkürzung, die die ID des Ereignisses definiert, in dem das Nutzlastfeld enthalten ist.

• Version, ein nicht signiertes Zeichen, das die Version des Ereignisses definiert, in dem das Nutzlastfeld enthalten ist.

• Dauer, eine Zeichenfolge, die den Namen des Nutzlastfelds definiert.

• Multiplikator. Für WPA muss die Dauer in Nanosekunden angegeben sein. Der Standardmultiplikator, mit dem die Millisekunden in Nanosekunden konvertiert werden, ist 1.000.000 (eine Million).

Wenn Sie eine Dauer für den Startpunkt definieren, wird die Dauer vom Endpunkt abgezogen. Ebenso wird, wenn Sie eine Dauer für den Endpunkt definieren, die Dauer zum Startpunkt hinzugerechnet.

Beispiel

Im folgenden Beispiel wird eine Region definiert, die endet, sobald eine andere Region gestartet wird. Um den Startpunkt zu berechnen, ziehen wir eine Dauer von unserem Endpunkt ab. Die Dauer wird im Nutzlastfeld "HiberHiberFileTime" angezeigt. Dann multiplizieren wir die Dauer mit 1.000.000, um sie in Nanosekunden umzuwandeln, und ziehen sie vom Endpunkt ab.

<Region Guid="{7D6BA3F6-BC04-4776-8A7F-93CF7F4E2B6D}"
   Name="FastStartup-Suspend-WriteHiberFile"
   FriendlyName="Subscribers for Create Session">
   <Region Guid="{93783B2C-A67F-49cb-89BC-BF305D7E2CEA}"
         Name="FastStartup-Suspend-Winlogon-CreateSession-Subscribers-Child"
         FriendlyName="Hiberfile Write">
      <Start>
         <Duration Provider="{331c3b3a-2005-44c2-ac53-77220c37d6b4}" 
                   Id="117"
                   Version="0"
                   Duration="HiberHiberFileTime"
                   Multiplier="1000000" />
      </Start>
      <Stop>
         <Region RegionGuid="{EC1BB2D9-4AA8-4d82-84AA-6042FF4CFBE3}" />
      </Stop>
   </Region>
</Region>

Regionen auf Basis anderer Regionen

Sie können einen Bereich definieren, dessen Start- und Endpunkte von anderen Regionen mithilfe eines Bereichs-knotens innerhalb des Start- oder End-knotens definiert werden. Dieser Bereichsknoten verfügt über ein obligatorisches Attribut, RegionGuid, das die GUID des Zielbereichs definiert.

Standardmäßig beginnt eine Region, deren Startpunkt auf einer anderen Region basiert, sobald die Startpunktregion beendet wird. Ebenso endet eine Region, deren Endpunkt auf einer anderen Region basiert, sobald die Endpunktregion beginnt. Sie können dieses Standardverhalten übersteuern, indem Sie ein optionales Attribut, Endpunkt, zum Region-Knoten hinzufügen. Endpunkt kann einen Wert von Start oder Stop haben und definiert, welcher Endpunkt der Region für das Start- oder Endereignis verwendet werden soll.

Beispiel

Die folgende Bereichsdefinition enthält Start- und Endpunkte, die von anderen Regionen definiert werden:

<Region Guid="{93783B2C-A67F-49cb-89BC-BF305D7E2CEA}"
        Name="FastStartup-Suspend-HiberInitTime"
        FriendlyName="Hiberfile Initialization">
   <Start>
      <Region RegionGuid="{5E81D74C-0CCC-43f9-8119-953F827BCD12}" />
   </Start>
   <Stop>
      <Region RegionGuid="{7D6BA3F6-BC04-4776-8A7F-93CF7F4E2B6D}" />
   </Stop>
</Region>

Regionen, die Container anderer Regionen sind

Regionen, die andere Regionen enthalten, nennt man Container. Container beginnen, sobald die erste Instanz eines enthaltenen Bereichs gestartet wird, und sie enden, sobald die letzte Instanz beendet wird. Diese Regionen verfügen über keine anderen Attribute.

RegionRoot ist ein Container für alle von Ihnen definierten Regionen. Somit beginnt RegionRoot, sobald die erste Instanz einer Region gestartet wird, und es endet, sobald die letzte Instanz einer Region beendet wird.

Um einen Containerbereich zu definieren, müssen Sie einfach nur einen Bereich ohne Start- oder Endpunkt definieren.

Beispiel

Im folgenden Beispiel ist Abonnenten für die Sitzungserstellung ein Container für Untergeordnete Abonnenten der Sitzungserstellung. Beachten Sie, dass Abonnenten für die Sitzungserstellung keinen Start- oder Endpunkt hat. Es startet, sobald die erste Instanz eines untergeordneten Bereichs gestartet wird, und endet, sobald die letzte Instanz eines untergeordneten Bereichs beendet wird.

<Region Guid="{A75D8F5D-E8F8-40b8-B453-5CC70DEAC06F}"
   Name="FastStartup-Suspend-Winlogon-CreateSession-Subscribers"
   FriendlyName="Subscribers for Create Session">
   <Region Guid="{93783B2C-A67F-49cb-89BC-BF305D7E2CEA}"
           Name="FastStartup-Suspend-Winlogon-CreateSession-Subscribers-Child"
           FriendlyName="Child of Subscribers for Create Session">
      <Start>
         <Region RegionGuid="{5E81D74C-0CCC-43f9-8119-953F827BCD12}" />
      </Start>
      <Stop>
         <Region RegionGuid="{7D6BA3F6-BC04-4776-8A7F-93CF7F4E2B6D}" 
                 Endpoint="Stop" />
      </Stop>
   </Region>
</Region>

Verwendung von Nutzlastfeldern zur Identifizierung von Ereignissen

Häufig sind die Ereignis-ID-Eigenschaften (Prozess-ID, Thread-ID und Aktivitäts-ID) nicht ausreichend, um bestimmte Szenarien zu identifizieren. Wenn z.B. ein Dienst gestartet wird, wird ein generisches Ereignis ausgelöst, das möglicherweise nicht identifiziert, welcher Dienst gestartet wurde. Wenn dies passiert, müssen Sie auf Nutzlastfelder zurückgreifen, um zusätzliche Informationen zu erhalten. In diesem Fall sollte eins der zusätzlichen Felder den Dienstnamen enthalten. Sie können diese Informationen verwenden, um die Start- und Endpunkte der Region näher zu bestimmen.

Um Nutzlastfelder als zusätzliche Ereignisidentifikatoren zu verwenden, fügen Sie einen oder mehrere NutzlastIdentifier-Knoten zu einem Start- oder Endknoten hinzu.

Der Knoten PayloadIdentifier verfügt über die folgenden Attribute:

• FieldName (erforderlich), der Name des Nutzlastfeldes.

• FieldValue (erforderlich), der Nutzlastwert.

• FieldValueRelationship (optional). Verwenden Sie IsEqual, um zu bestimmen, dass das Ereignis den Nutzlastwert enthalten muss. Verwenden Sie DoesNotContain, um zu bestimmen, dass das Ereignis den Nutzlastwert nicht enthalten darf. Wenn dieses Attribut nicht definiert wird, ist der Standardwert IsEqual.

Hinweis

Beachten Sie die Groß-/Kleinschreibung bei Nutzlastfeldern, und vergewissern Sie sich, dass die XML-Definition vollständig mit dem Nutzlastwert übereinstimmt. Wenn z.B. der Wert eines Nutzlastfeldes 00000 beträgt, muss der Nutzlastwert in der Bereichsdefinition auch mit 00000 angegeben werden.

Beispiel

Das folgende Beispiel zeigt NutzlastIdentifikator-Knoten sowohl für den Start- als auch für den Endpunkt:

<Region Guid="{AB719FB1-D863-4305-AE8E-F21281899A85}"
        Name="FastStartup-ConsoleSessionDisconnect"
        FriendlyName="Console Session Disconnect">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="801" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="8" />
      <PayloadIdentifier FieldName="Key" FieldValue="00000" />
   </Start>
   <Stop>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="802" Version="0" />
      <PayloadIdentifier FieldName="Event"
                         FieldValue="20"
                         FieldValueRelationship="DoesNotContain" />
   </Stop>
</Region>

Übereinstimmende Ereignisse für Regionen

WPA gleicht Startereignisse mit dem Endereignissen ab, um Bereiche zu bilden. Dieser Prozess wird Ereignisabgleich genannt. Auf der Ereignisebene versucht WPA, ein einzelnes Start- oder Endereignis im Hinblick auf dessen Anbieter-ID, Ereignis-ID, Ereignisversion und alle zusätzlichen angegebenen Nutzlastfelder miteinander abzugleichen.

Der Abgleich kann auch auf die Regionsebene ausgeweitet werden, wobei Kriterien definiert werden können, die sowohl von den Start- als auch den Endpunkten erfüllt werden müssen. Auf der Regionsebene können Sie festlegen, dass beide Punkte übereinstimmende Thread-IDs, Prozess-IDs und Aktivitäts-IDs aufweisen müssen. Darüber hinaus können Sie auch Nutzlastkriterien auf der Regionsebene definieren.

Sie können den Abgleich auf der Regionsebene verwenden, indem Sie einen Knoten Übereinstimmung innerhalb des Knotens Region einfügen. Der Knoten Übereinstimmung enthält einen untergeordneten Knoten, Ereignis, der eine beliebige Kombination der folgenden Attribute aufweisen kann:

• TID="true" – übereinstimmende Thread-IDs erforderlich

• PID="true" – übereinstimmende Prozess-IDs erforderlich

• AID="true" – übereinstimmende Aktivitäts-IDs erforderlich

Der Knoten Ereignis kann über einen optionalen untergeordneten Knoten Payload verfügen, der ein Attribut FieldName enthält. Dieser Knoten erfordert, dass die Nutzlastwerte der Start- und Endknoten für den angegebenen FieldName übereinstimmen.

Alternativ kann der Knoten Payload auch ein optionales Attribut enthalten, TargetFieldName. Wenn dieses Attribut definiert wird, entspricht FieldName nur einem Nutzlastfeld im Startknoten, während TargetFieldName einem Nutzlastfeld im Endknoten entspricht.

Beispiel

Im folgenden Beispiel wird ein Bereich gebildet, wenn das Startereignis ein Nutzlastfeld enthält, SubscriberName, dessen Wert mit dem eines Nutzlastfelds, Client, im Endknoten übereinstimmt. Die Start- und Endereignisse müssen auch übereinstimmende Thread-IDs aufweisen.

<Region Guid="{A75D8F5D-E8F8-40b8-B453-5CCC70DEAC06F}"
        Name="FastStartup-Suspend-Winlogon-CreateSession-Subscribers"
        FriendlyName="Subscribers for Create Session">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="805" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="0" />
   </Start>
   <Stop>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="806" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="0" />
   </Stop>
   <Match>
      <Event TID="true">
         <Payload FieldName="SubscriberName" TargetFieldName="Client" />
      </Event>
   </Match>
</Region>

Filtern eines Bereichs anhand einer Bedingung

WPA kann eine Region anhand einer Bedingung oder eines Triggers einschließen oder ausschließen, wobei dies ein Ereignis oder eine andere Region sein kann. Der Trigger wird in einem Filter-element angegeben und der Bereich, der Filter enthält, ist das Ziel.

Wenn der Trigger ein Bereich ist, muss Filter die Regions-ID enthalten.

Wenn der Trigger ein Ereignis ist, muss Filter ein Ereignis-element mit der ProviderId des ETW-Anbieters und mindestens eines der folgenden Attribute enthalten: Id, Version, OpCode und Type.

Id und Version werden weiter oben unter Regionstypen beschrieben. OpCode ist jeder von Ihnen bestimmte Wert. Typ gibt die Filterart des Zielbereichs an, wobei dieser anhand der in der folgenden Tabelle beschriebenen Bedingungen entweder eingeschlossen oder ausgeschlossen ist.

Filtertyp	Beschreibung
aus	Schließen Sie den Zielbereich aus, wenn das auslösende Ereignis oder die Region gefunden wurde.
OutPost	Schließen Sie den Zielbereich aus, wenn das Ziel nach dem letzten auslösenden Ereignis oder Bereich aufgetreten ist.
OutPrev	Schließen Sie den Zielbereich aus, wenn das Ziel vor dem ersten auslösenden Ereignis oder Bereich aufgetreten ist.
In	Schließen Sie den Zielbereich ein, wenn das auslösende Ereignis oder die Region gefunden wurde.
InPost	Schließen Sie den Zielbereich nur dann ein, wenn das Ziel nach dem letzten auslösenden Ereignis oder Bereich aufgetreten ist.
InPrev	Schließen Sie den Zielbereich nur ein, wenn das Ziel vor dem ersten auslösenden Ereignis oder Bereich aufgetreten ist.

Beziehungen zwischen übergeordneten und untergeordneten Elementen

Sie können eine Region innerhalb einer anderen Region definieren, um eine Beziehung zwischen übergeordneten und untergeordneten Elementen herzustellen. Damit eine Region als übergeordnetes Element gilt, muss ihre Anfangszeit früher als oder gleich der Startzeit der untergeordneten Region sein. Außerdem muss die Endzeit später als oder gleich der Stoppzeit des untergeordneten Bereichs sein. Wenn diese Bedingungen nicht erfüllt sind, kann keine Beziehung zwischen übergeordneten und untergeordneten Elementen hergestellt werden.

Um zusätzliche Kriterien für eine übergeordnete Region zu bestimmen, verwenden Sie den übergeordneten Knoten innerhalb eines Übereinstimmung-sknotens. Der übergeordnete Knoten weist die gleichen Attribute und untergeordneten Knoten auf wie der Ereignis-knoten, der im Abgleich auf der Regionsebene verwendet wird. Sie können vorgeben, dass die übergeordneten und untergeordneten Regionen dieselbe Thread-ID, Prozess-ID, Aktivitäts-ID und eine beliebige Anzahl übereinstimmender Nutzlastfelder aufweisen müssen.

Wenn Sie bei der Verwendung von Nutzlastfeldern nur das Attribut FieldName bestimmen, müssen sowohl die übergeordneten als auch die untergeordneten Regionen übereinstimmende Nutzlastwerte für dieses Feld aufweisen. Wenn Sie auch das Attribut TargetFieldName definieren, dann gilt das Attribut FieldName sowohl für das übergeordnete als auch für das untergeordnete Element, d. h. die untergeordnete Region muss einen Nutzlastwert für das Feld FieldNameaufweisen, der dem Nutzlastwert für das Feld TargetFieldNamein der übergeordneten Region entspricht.

Wenn ein untergeordnetes Element mehr als ein potenzielles übergeordnetes Element hat, wird das übergeordnete Element mit der frühesten Startzeit ausgewählt.

Beispiel

Im folgenden Beispiel werden Kriterien für ein übergeordnetes Element definiert. Das übergeordnete Element muss über eine übereinstimmende Thread-ID verfügen, und ein Nutzlastwert für das Feld SubscriberName im untergeordneten Element muss mit einem Wert für das Feld Client im übergeordneten Element übereinstimmen.

<Region Guid="{A75D8F5D-E8F8-40b8-B453-5CC70DEAC06F}"
        Name="FastStartup-Suspend-Winlogon-CreateSession-Subscribers"
        FriendlyName="Subscribers for Create Session">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="805" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="0" />
   </Start>
   <Stop>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="806" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="0" />
   </Stop>
   <Match>
      <Event TID="true">
         <Payload FieldName="SubscriberName" TargetFieldName="Client" />
      </Event>
      <Parent TID="true">
         <Payload FieldName="SubscriberName" TargetFieldName="Client" />
      </Parent>
   </Match>
</Region>

Selbstschachtelnde Regionen

Self-Nesting ist ein optionales Feature, das die Beziehungen zwischen übergeordneten und untergeordneten Elementen optimiert.

Eine Selbstschachtelnde Region ist eine Region, deren Dauer vollständig innerhalb der Dauer einer gleichgeordneten Region enthalten ist. Diese Region wird praktisch der länger andauernden gleichgeordneten Region untergeordnet.

Nehmen Sie z.B. an, dass die Selbstschachtelung für die folgenden Regionen aktiviert ist:

• Übergeordnete Region A

• Untergeordnete Region B1, die zum Zeitpunkt 0 beginnt und zum Zeitpunkt 6 endet

• Untergeordnete Region B2, die zum Zeitpunkt 2 beginnt und zum Zeitpunkt 5 endet

• Untergeordnete Region B3, die zum Zeitpunkt 3 beginnt und zum Zeitpunkt 4 endet

In diesem Beispiel wird B2 zu einer untergeordneten Region von B1, und B3 wird zu einer untergeordneten Region von B2. Wenn Sie diese Art von Beziehung zwischen über- und untergeordneten Elementen erstellen, wird das übergeordnete Element mit der Anfangszeit, die der Anfangszeit des untergeordneten am nächsten kommt, ausgewählt.

Um die Selbstschachtelung zu aktivieren, fügen Sie einen SelfNest-Knoten innerhalb des KnotensÜbereinstimmung ein.

Der SelfNest-Knoten verfügt über keine erforderlichen Parameter. Sie können jedoch dieselben Übereinstimmungsparameter verwenden, die für die Erstellung gewöhnlicher Beziehungen zwischen übergeordneten und untergeordneten Elementen verwendet werden. Weitere Informationen finden Sie unter Beziehungen zwischen übergeordneten und untergeordneten Elementen weiter oben in diesem Artikel.

Beispiele

Im folgenden Beispiel wird ein Match-Tag definiert, der die Selbstverschachtelung einfach aufruft:

<Match>
   <SelfNest />
</Match>

Im folgenden Beispiel wird ein komplexeres Selbstschachtelungsszenario definiert, für das übereinstimmende Thread-IDs und Nutzlastfelder erforderlich sind:

<Match>
   <SelfNest TID="true">
      <Payload FieldName="SubscriberName" />
   </SelfNest>
</Match>

Namen für Instanzen

Sie können jeder Instanz eines übereinstimmenden Bereichs mithilfe des Knotens Benennung einen eindeutigen Namen zuweisen. Die Benennung ist sinnvoll, wenn Sie über eine große Anzahl von Instanzen derselben Region verfügen oder Regionen aufgrund anderer Kriterien kategorisieren müssen. Instanzennamen können sich entweder auf Nutzlastfelder oder auf Beziehungen mit anderen Regionen beziehen.

Instanzen können basierend auf Nutzlastwerten mithilfe des Knotens PayloadBased innerhalb eines Benennungsknotens benannt werden. Für den Knoten PayloadBased ist ein Attribut namens NameField erforderlich, welches das Nutzlastfeld definiert, dessen Werte Sie als Instanzennamen verwenden möchten. Diese Nutzlastfelder können entweder im Start- oder im Endpunkt für die Region enthalten sein.

Das folgende Im Beispiel zeigt eine Region mit einem nutzlastbasierten Benennungsknoten:

<Region Guid="{9261872F-D3A7-4d80-BDE3-8479CC920639}"
        Name="FastStartup-Suspend-Winlogon-EndShell-CallSubscriber"
        FriendlyName="Call Subscriber for End Shell">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="811" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="13" />
   </Start>
   <Stop>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="812" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="13" />
   </Stop>
   <Match>
      <Event PID="true" />
      <Parent PID="true" />
   </Match>
   <Naming>
      <PayloadBased NameField="SubscriberName" />
   </Naming>
</Region>

Im vorherigen Beispiel gibt der Benennungsknoten an, dass entweder das Start- oder das Endereignis ein Nutzlastfeld namens SubscriberName enthält. Für jede Instanz des erstellten Bereichs ist der Instanzenname der entsprechende Nutzlastwert.

Hinweis

Beim Benennen von Regionsinstanzen überprüft WPA zuerst das Startereignis für das entsprechende Nutzlastfeld. Wenn keins gefunden wird, durchsucht WPA das Endereignis für das Nutzlastfeld. Wenn in beiden Ereignissen keine Übereinstimmung gefunden wird, wird ein Fehler in die Konsole gedruckt.

Manchmal sind die Angaben in der Nutzlast nicht die einzigen gewünschten Informationen. Wenn z.B. die Information in der enthaltenen Nutzlast eine Geräte-ID ist, wäre es wünschenswert, diese Information auf eine Gerätebeschreibung und einen Namen zurückführen zu können. Unterstützte Typ-attribute sind:

• Device, verknüpft einen Namen und eine Beschreibung

• GUID, verknüpft die GUID mit der Region

• CLSID, verknüpft einen Klassennamen mit einer Klassen-ID

• PID, verknüpft den Prozessnamen mit der Region

<Naming>
   <PayloadBased NameField="SubscriberName" Type="Device" />
</Naming>

Wenn der Nutzlastwert sowohl in den Start- als auch in den Endpunkten gefunden werden kann, können Sie das optionale Attribut InstanceEndpoint verwenden, um zu definieren, welcher Punkt verwendet werden soll. Mögliche Werte für InstanceEndpoint sind Start und Stop.

<Naming>
   <PayloadBased NameField="SubscriberName" InstanceEndpoint="Start" />
</Naming>

Sie können eine Region auch aufgrund der Beziehungen zu anderen Regionen benennen. Um sie einer anderen Region zuzuordnen, fügen Sie einem Benennung-sknoten einen RegionBased-Knoten hinzu. Für den Knoten RegionBased sind vier Attribute erforderlich:

• RegionGuid, die GUID der zugeordneten Region.

• Relation, ein bedingter Wert, der die Beziehung zwischen der von Ihnen definierten Region und der Region, der Sie sie zuordnen, beschreibt. Derzeit ist IsPresentdie einzige unterstützte Beziehung, was bedeutet, dass die Bedingung wahr ist, wenn die zugeordnete Region irgendwo in der Ablaufverfolgung gefunden wird.

• IfRelationTrue, Zeichenfolgenwert, der als Instanzenname verwendet wird, wenn die durch Relation beschriebene Beziehung wahr ist.

• IfRelationFalse, Zeichenfolgenwert, der als Instanzenname verwendet wird, wenn die durch Relation beschriebene Beziehung falsch ist.

Im folgenden Beispiel wird eine Region definiert, die aufgrund einer Region benannt wurde. Wenn eine Region mit einer übereinstimmenden GUID irgendwo in der Ablaufverfolgung gefunden wird, wird jede Instanz Launch als Warm benannt. Andernfalls wird jede Instanz als Cold benannt.

<Region Guid="{C99EFA90-F645-4A24-9576-740351171BD0}"
        Name="WinStoreAppActivationDuration"
        FriendlyName="Launch">
   <Start>
      <Event Provider="{315a8872-923e-4ea2-9889-33cd4754bf64}" Id="5901" Version="0" />
      <PayloadIdentifier FieldName="SqmableContractID" FieldValue="Windows.Launch" />
   </Start>
   <Stop>
      <Event Provider="{315a8872-923e-43a2-9889-33cd4754bf64}" Id="5902" Version="0" />
      <PayloadIdentifier FieldName="SqmableContractID" FieldValue="Windows.Launch" />
   </Stop>
   <Match>
      <Event PID="true" />
   </Match>
   <Naming>
      <RegionBased RegionGuid="{1539A93E-129C-4602-A011-431E7F73A353}" Relation="IsPresent" IfRelationTrue="Warm" IfRelationFalse="Cold" />
   </Naming>
</Region>

Hinweis

Sie können Instanzennamen in WPA anzeigen, indem Sie den Mauszeiger über eine Regionsinstanz im Schaubild Regions auf Interest halten.

Metadaten

Sie können einer Regionsdefinition zusätzliche Informationen in Form von Metadaten hinzufügen, die in einem Metadaten-knoten enthalten sind. Sie können z.B. Informationen in Metadaten einfügen, welche die Regionskriterien erläutern, damit ein anderer Benutzer den Zweck der Region einfacher verstehen kann. Metadaten sind einfach zusätzliche Daten – sie wirken sich nicht auf die Verarbeitung von Regionen aus.

WPA fügt diese Metadaten jeder Regionsinstanz in der Diagrammansicht des Schaubilds Regions of Interest hinzu. Um Metadaten für übereinstimmende Ereignisse in WPA anzuzeigen, erweitern Sie einfach den Bereich in der Diagrammansicht und scrollen Sie zu den gewünschten Metadaten. WPA weist den Metadaten eine eindeutige Zahl zu und der Name des Knotens wird als Spalteninformationen angezeigt.

Beispiel

Das folgende Beispiel enthält einen Knoten Metadaten in der Regionsdefinition:

<Region Guid="{F466EE67-192C-4772-B13D-052CCD2D70B3}"
        Name="FastStartup-Suspend-Winlogon-Logoff-Subscribers"
        FriendlyName="Subscribers for Logoff">
   <Start>
      <Event Provider="{dbe9b383-7cf3-4331-91cc-a3cb16a3b538}" Id="805" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="3" />
   </Start>
   <Stop>
      <Event Provider="{db39b383-7cf3-4331-91cc-a3cb16a3b538}" Id="806" Version="0" />
      <PayloadIdentifier FieldName="Event" FieldValue="3" />
   </Stop>
   <Match>
      <Event>
         <Payload FieldName="Event" />
      </Event>
   </Match>
   <Naming>
      <PayloadBased NameField="SubscriberName" />
   </Naming>
   <Metadata>
      <FAS.TestNode>yes</FAS.TestNode>
   </Metadata>
</Region>

Zugehörige Themen

Interessenbereiche

WPA-Features