7 Appendix B: Product Behavior
The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.
Windows Vista operating system
Windows Server 2008 operating system
Windows 7 operating system
Windows Server 2008 R2 operating system
Windows 8 operating system
Windows Server 2012 operating system
Windows 8.1 operating system
Windows Server 2012 R2 operating system
Windows 10 operating system
Windows Server 2016 operating system
Windows Server operating system
Windows Server 2019 operating system
Windows Server 2022 operating system
Windows 11 operating system
Windows Server 2025 operating system
Exceptions, if any, are noted in this section. If an update version, service pack or Knowledge Base (KB) number appears with a product name, the behavior changed in that update. The new behavior also applies to subsequent updates unless otherwise specified. If a product edition appears with the product version, behavior is different in that product edition.
Unless otherwise specified, any statement of optional behavior in this specification that is prescribed using the terms "SHOULD" or "SHOULD NOT" implies product behavior in accordance with the SHOULD or SHOULD NOT prescription. Unless otherwise specified, the term "MAY" implies that the product does not follow the prescription.
<1> Section 2.1: The authorization constraints in Windows are as follows: All performance logging abilities are limited to members of the Administrators or Performance Logs User Group. For more information, see [MSDN-LUACCESS].
<2> Section 2.2.2.11: The Performance Logs and Alerts Protocol uses the plaFlagArray type of the IValueMapItem to set and retrieve kernel control flags that are used by ETW from the server. ETW publicly documents 21 different categories of kernel flags (exposed through the EnableFlags property of the EVENT_TRACE_PROPERTIES structure described in [MSDN-EVENT_TRACE_PROPERTIES]) that enable specific kernel events to be logged to ETW; however, the Windows kernel internally has defined 13 more categories of kernel flags that are used for internal purposes and are not exposed publicly. Together, both the publicly documented kernel event flags and Windows-internal kernel event flags are represented via eight separate ULONG values that are attached at the end of the EVENT_TRACE_PROPERTIES structure. Since these values are not meant to be OR'd together when they are returned to the client, the plaFlagArray is used. The following table indicates the values of the flags that enable Windows kernel ETW events:
|
Flag Name |
Flag Value |
|---|---|
|
Registry Events |
0x00020000 |
|
Hard Page Fault Events |
0x000f02000 |
|
Process and Thread Events |
0x00000003 |
|
Process Events |
0x00000001 |
|
Thread Events |
0x00000002 |
|
Disk I/O Events |
0x00000100 |
|
Disk I/O Events (Version 2) |
0x00000400 |
|
Image Load/Unload Events |
0x00000004 |
|
Page Fault Events |
0x00001000 |
|
File Events |
0x00000200 |
|
TCP/IP Network Events |
0x00010000 |
|
ALPC Events |
0x00100000 |
|
Split I/O Events |
0x00200000 |
|
Process Counter Events |
0x00000008 |
|
File I/O Events |
0x02000000 |
|
File I/O Initialization Events |
0x04000000 |
|
Print Kernel Debug Statements |
0x00040000 |
|
Heap Range and Virtual Allocation Events |
0x20000001 |
|
Sampling Profiler |
0x20000002 |
|
Thread Context Switch Events |
0x20000004 |
|
Enables Working Set Flush Markers |
0x20000008 |
|
Driver Function Logging |
0x20000010 |
|
Deferred Procedure Call Events |
0x20000080 |
|
Context Switch Events: Compact Format |
0x20000100 |
|
Thread Dispatching and Readying |
0x20000200 |
|
Thread Priority Adjustment Events |
0x20002000 |
|
Interrupt Service Routine Events |
0x20004000 |
|
Virtual Memory Allocation Events |
0x20008000 |
|
Kernel Spinlock Events (not in Vista) |
0x20010000 |
|
Kernel Queue Events (not in Vista) |
0x20020000 |
|
Periodic Memory List Information |
0x20080000 |
|
Contiguous Page Allocation Events |
0x20100000 |
|
System Call Entry/Exit Events |
0x40000040 |
|
System Power Management Events |
0x80008000 |
<3> Section 2.2.2.11: On Windows, PLA_S_PROPERTY_IGNORED is not added to the ValueMap for IApiTracingDataCollector::FileName.
<4> Section 2.2.2.11: On Windows, PLA_E_PROPERTY_CONFLICT is not added to the ValueMap for ITraceDataCollector::MaximumBuffers when MaximumBuffers is less than MinimumBuffers.
<5> Section 2.2.2.11: On Windows, PLA_E_PROPERTY_CONFLICT is not added to the ValueMap for ITraceDataCollector::Guid when isKernelTrace is true and the specified PLA-UID does not match the kernel PLA-UID.
<6> Section 2.2.3.1: On Windows, if the "z" or "zz" pattern is specified for the file or subdirectory name, and the time zone offset is a positive value, then the value of the offset will be preceded by two negative signs. For example, if the time zone offset is "+8", then the value that will be used for the file or subdirectory name will be "--8" (two negative signs followed by the offset value).
<7> Section 2.2.11.1.2: Out of the 16 keywords reserved by Windows, 8 are currently in use and they are explained in ([MSDN-PLA-KeywordType]).
<8> Section 2.2.11.2.2: On Windows this is done by using the wevtutil utility, which ships as part of Windows Vista. To register the manifest, run the following command: "wevtutil.exe im <ManifestFileName>".
<9> Section 2.2.11.2.3: The full signature of the callback function is described at [MSDN-PLA-EnableCallBack].
<10> Section 2.2.11.2.4: It does so by calling the EventRegister method [MSDN-PLA-EventReg] in user-mode, and EtwRegister ([MSDN-PLA-LevelType]) in kernel-mode, passing in its PLA-UID and the enable callback as parameters.
<11> Section 2.2.13.1: The following describes how performance counters can be exposed on Windows. Performance counter providers define the counter sets and performance counters in an XML manifest file. The XML manifest needs to comply with the performance counter schema [MSDN-PLA-PCS]. Before the performance counters that are defined in the XML file are discoverable, the XML manifest file needs to be installed on the machine; Windows stores much of this information, including the PLA-UIDs of the performance counter providers and counter sets, in the registry. This also includes a link to the resource file that contains the localized name and description strings for the performance counters. The XML manifest is installed on the machine by using the following command: "lodctr.exe /M: <XML Manifest File>" [MSDN-PLA-Lodctr].
At runtime, the performance counter provider needs to register itself with the subsystem, and then register the counter sets and their corresponding performance counters that it defined in the XML manifest file. The provider registration, done by calling the PerfStartProvider method [MSDN-PLA-PSPF], enables the performance subsystem to identify the performance counter provider, while the second registration call, accomplished using the PerfSetCounterSetInfo method [MSDN-PLA-PSCSIF], enables the subsystem to associate the performance counters to the data provider.
Once the provider has registered the different counter sets and their corresponding performance counters through the PerfSetCounterSetInfo method, the data provider can then create instances of the counter sets by calling the PerfCreateInstance method [MSDN-PLA-PCIF]. The subsystem is made aware of each newly created counter set instance in order to expose this information to interested performance counter consumers. Once this has been completed, the performance counter provider can now update the performance counter values using the following methods that are exposed by the subsystem (note that which method is used depends on the type of the performance counter): PerfSetULongCounterValue [MSDN-PLA-PSUCVF], PerfSetULongLongCounterValue[MSDN-PLA-PSULCVF], or PerfSetCouterRefValue [MSDN-PLA-PSCRVF]. A performance counter provider can update the value of any instance of a performance counter using these methods at any arbitrary interval. At the end, the performance counter provider unregisters with the subsystem using the PerfStopProvider method [MSDN-PLA-PSTPF]; at this point, performance counter consumers cannot query for those performance counter values that were unregistered.
<12> Section 3.2.4.1: In Windows Vista, if the Segment property is enabled (through the IDataCollectorSet::Segment method) and the SegmentMaxSize is set to a value greater than zero, PLA will stop the data collector set when the log file size reaches the SegmentMaxSize value.
<13> Section 3.2.4.1.5: Localized strings can be specified in the form @binary,#id, where binary is the EXE or DLL that contains the localized resource string, and id is the string resource identifier.
If the description is set to the @binary,#id form, when retrieving the description the callers will receive the localized string. To retrieve the original description string, the client can use the IDataCollectorSet::DescriptionUnresolved method.
<14> Section 3.2.4.1.8: Localized strings can be specified in the form @binary,#id, where binary is the EXE or DLL that contains the localized resource string and id is the string resource identifier. If the display name is set to the @binary,#id form, it is returned as the localized string. The original display name string can be retrieved by calling the IDataCollectorSet::DisplayNameUnresolved method, as specified in section 3.2.4.1.9.
<15> Section 3.2.4.1.23: In Windows Vista, if the Segment property has been enabled (through the IDataCollectorSet::Segment method) and the SegmentMaxSize is set to a value greater than zero, the Performance Logs and Alerts Protocol stops the data collector set when the log file size reaches the SegmentMaxSize value.
<16> Section 3.2.4.1.52: If credentials are not specified, the Performance Logs and Alerts Protocol tries to run the set as LocalSystem if the current user is a member of the administrator group.
<17> Section 3.2.4.5: Gaps in the opnum numbering sequence apply to Windows as follows.
|
Opnum |
Description |
|---|---|
|
8 |
Only used locally by Windows, never remotely. |
|
28 |
Only used locally by Windows, never remotely. |
|
31 |
Only used locally by Windows, never remotely. |
<18> Section 3.2.4.7: If QueryNetworkAdapters is specified, and a report is also being generated, then the network adapter information is written into a table; the name of the table is "networkInformation".
<19> Section 3.2.4.7.14: The Performance Logs and Alerts Protocol collects registry data from the following registry hives:
HKEY_CLASSES_ROOT
HKEY_CURRENT_CONFIG
HKEY_CURRENT_USER
HKEY_LOCAL_MACHINE
HKEY_USERS
To collect a registry value, specify the full path to the value name, for example, \HKEY_LOCAL_MACHINE\MyKey\MyValue.
To collect all of the values under a registry key, specify the full path to the registry key, for example, \HKEY_LOCAL_MACHINE\MyKey\.
To collect all of the values under a registry key and its subkeys, use two backslashes for the last path delimiter, for example, \\computername\HKEY_LOCAL_MACHINE\MyKey\\. PLA recursively collects the registry data down to the level specified in IConfigurationDataCollector::RegistryMaxRecursiveDepth.
To collect registry information from a remote computer, include the computer name at the beginning of the registry path, for example, \\computername\HKEY_LOCAL_MACHINE\MyKey\MyValue.
<20> Section 3.2.4.8: In Windows, these events are logged to the Microsoft-Windows-Diagnosis-PLA/Operational event log channel with Event ID 2031. This channel logs operational data for the Performance, Logs, and Alerts service.
<21> Section 3.2.4.8.4: The event identifier of the event is 2031 and the channel used is Microsoft-Windows-Diagnosis-Pla/Operational.
<22> Section 3.2.4.9: On Windows, the following properties of the ITraceDataCollector are only updated when the IDataCollectorSet::Query method is called and only if the data collector set is of type TraceSession or BootTraceSession: BuffersLost, BuffersWritten, EventsLost, FreeBuffers, RealTimeBuffersLost, SessionThreadId. The values of these properties are not updated when the IDataCollectorSet::Start method is called. The values of the above properties are not updated by calling the IDataCollectorSet::Query or IDataCollectorSet::Start methods if the data collector set type is SystemDataCollectorSet or ServerDataCollectorSet.
<23> Section 3.2.4.9: On Windows, the following properties of the ITraceDataCollector are only updated when the IDataCollectorSet::Query method is called and only if the data collector set is of type TraceSession or BootTraceSession: BuffersLost, BuffersWritten, EventsLost, FreeBuffers, RealTimeBuffersLost, SessionThreadId. The values of these properties are not updated when the IDataCollectorSet::Start method is called. The values of the above properties are not updated by calling the IDataCollectorSet::Query or IDataCollectorSet::Start methods if the data collector set type is SystemDataCollectorSet or ServerDataCollectorSet.
<24> Section 3.2.4.9: On Windows, the following properties of the ITraceDataCollector are only updated when the IDataCollectorSet::Query method is called and only if the data collector set is of type TraceSession or BootTraceSession: BuffersLost, BuffersWritten, EventsLost, FreeBuffers, RealTimeBuffersLost, SessionThreadId. The values of these properties are not updated when the IDataCollectorSet::Start method is called. The values of the above properties are not updated by calling the IDataCollectorSet::Query or IDataCollectorSet::Start methods if the data collector set type is SystemDataCollectorSet or ServerDataCollectorSet.
<25> Section 3.2.4.9: On Windows, the following properties of the ITraceDataCollector are only updated when the IDataCollectorSet::Query method is called and only if the data collector set is of type TraceSession or BootTraceSession: BuffersLost, BuffersWritten, EventsLost, FreeBuffers, RealTimeBuffersLost, SessionThreadId. The values of these properties are not updated when the IDataCollectorSet::Start method is called. The values of the above properties are not updated by calling the IDataCollectorSet::Query or IDataCollectorSet::Start methods if the data collector set type is SystemDataCollectorSet or ServerDataCollectorSet.
<26> Section 3.2.4.9: On Windows, the SessionId property is updated upon calling IDataCollectorSet::Query or IDataCollectorSet::Start methods only if the type of the data collector set is TraceSession or BootTraceSession. It is not updated by calling the IDataCollectorSet::Query or IDataCollectorSet::Start methods if the data collector set is SystemDataCollectorSet or ServerDataCollectorSet.
<27> Section 3.2.4.9: On Windows, the following properties of the ITraceDataCollector are only updated when the IDataCollectorSet::Query method is called and only if the data collector set is of type TraceSession or BootTraceSession: BuffersLost, BuffersWritten, EventsLost, FreeBuffers, RealTimeBuffersLost, SessionThreadId. The values of these properties are not updated when the IDataCollectorSet::Start method is called. The values of the above properties are not updated by calling the IDataCollectorSet::Query or IDataCollectorSet::Start methods if the data collector set type is SystemDataCollectorSet or ServerDataCollectorSet.
<28> Section 3.2.4.9.16: The Performance Logs and Alerts Protocol provides the client defined value of MaximumBuffers; however, this cannot be the maximum allowed buffers on the server. Upon receiving the user-defined MaximumBuffers supplied by this protocol, ETW on Windows checks to see whether this value is greater than the system-defined number of minimum buffers; this value is set to the number of processors on the system plus two (0x00000002). If it is NOT greater, then ETW assigns MaximumBuffers the value of the system-defined minimum number of buffers and moves to the next check. If it is greater, ETW leaves the value of MaximumBuffers that was passed in by the user and moves to the next check. In this second check, ETW checks that the MaximumBuffers value is less than the system-defined maximum allowed buffers. This system-defined value is calculated by taking the total available memory (either paged or nonpaged depending on how the ETW session was specified by the client calling the Performance Logs and Alerts Protocol), dividing it by 10 (the percent of total memory at most that will be dedicated to ETW) and then dividing that intermediate result by the specified buffer size. If this system-defined value is smaller than the value of MaximumBuffers, then MaximumBuffers is assigned this system-defined value; otherwise, the MaximumBuffers value remains the same.
<29> Section 3.2.4.9.17: The Performance Logs and Alerts Protocol provides the client defined value of MaximumBuffers; however, this cannot be the maximum allowed buffers on the server. Upon receiving the user-defined MaximumBuffers supplied by the protocol, ETW in Windows, checks to see whether this value is greater than the system-defined number of minimum buffers; this value is set to the number of processors on the system plus two (0x00000002). If it is not greater, ETW assigns MaximumBuffers the value of the system-defined minimum number of buffers and moves to the next check. If it is greater, ETW leaves the value of MaximumBuffers that was passed in by the user and moves to the next check. In this second check, ETW ensures that the MaximumBuffers value is less than the system-defined maximum allowed buffers. This system-defined value is calculated by taking the total available memory (either paged or nonpaged depending on how the ETW session was specified by the client calling the protocol), dividing it by 10 (the percentage of total memory at most that will be dedicated to ETW), and dividing the intermediate result by the specified buffer size. If this system-defined value is smaller than the value of MaximumBuffers, then MaximumBuffers is assigned this system-defined value; otherwise, the MaximumBuffers value remains the same.
<30> Section 3.2.4.9.18: The client uses the Performance Logs and Alerts Protocol to specify the value of MinimumBuffers; however, this cannot be the minimum number of buffers allocated on applicable Windows Server releases. Upon receiving the user-defined MinimumBuffers supplied by the protocol, ETW on Windows will first check to see whether this value is greater than the system-defined number of minimum buffers; this value is set to the number of processors on the system plus two (0x00000002). If it is NOT greater, then ETW will assign MinimumBuffers the value of the system-defined minimum number of buffers and move to the next check. If it is greater, then ETW will leave the value of MinimumBuffers that was passed in by the user and move to the next check. In this second check, ETW will make sure that the MinimumBuffers value is less than the system-defined maximum allowed buffers. This system-defined value is calculated by taking the total available memory (either paged or non-paged depending on how the ETW session was specified by the client calling the Performance Logs and Alerts Protocol), dividing it by 10 (the percentage of total memory at most that will be dedicated to ETW) and then dividing that intermediate result by the specified buffer size. If this system-defined value is smaller than the value of MinimumBuffers, then MinimumBuffers is assigned this system-defined value; otherwise, the MinimumBuffers value remains the same.
<31> Section 3.2.4.9.19: The client uses the Performance Logs and Alerts Protocol to specify the value of MinimumBuffers; however, this cannot be the minimum number of buffers allocated on applicable Windows Server releases. Upon receiving the user-defined MinimumBuffers supplied by the Performance Logs and Alerts Protocol, ETW on Windows, will first check to see whether this value is greater than the system-defined number of minimum buffers; this value is set to the number of processors on the system plus two (0x00000002). If it is NOT greater, then ETW will assign MinimumBuffers the value of the system-defined minimum number of buffers and move to the next check. If it is greater, then ETW will leave the value of MinimumBuffers that was passed in by the user and move to the next check. In this second check, ETW will make sure that the MinimumBuffers value is less than the system-defined maximum allowed buffers. This system-defined value is calculated by taking the total available memory (either paged or non-paged depending on how the ETW session was specified by the client calling the Performance Logs and Alerts Protocol), dividing it by 10 (the percentage of total memory at most that will be dedicated to ETW) and then dividing that intermediate result by the specified buffer size. If this system-defined value is smaller than the value of MinimumBuffers, then MinimumBuffers is assigned this system-defined value; otherwise, the MinimumBuffers value remains the same.
<32> Section 3.2.4.9.20: In Windows, NumberOfBuffers is an indication of how many buffers the ETW system is using for a particular trace session. When the client sets this property, the only change that will take place is that the NumberOfBuffers property of the ITraceDataCollector will be set to the client value. If the client were then to retrieve this, it would get the same value that it had set. However, if the Query method is executed on the IDataCollectorSet, and the IDataCollectorSet contains ITraceDataCollectors, then the NumberOfBuffers will be updated to reflect the number of buffers that ETW is using for its tracing session. In this case, the value of the NumberOfBuffers can be different than what the client originally had specified, but will be greater than or equal to the value of the MinimumBuffers property, and less than or equal to the value of the MaximumBuffers property.
<33> Section 3.2.4.9.21: In Windows, NumberOfBuffers is an indication of how many buffers the ETW system is using for a particular trace session. When the client sets this property, the only change that will take place is that the NumberOfBuffers property of the ITraceDataCollector will be set to the client value. If the client were then to retrieve this, it would get the same value that it had set. However, if the Query method is executed on the IDataCollectorSet, and the IDataCollectorSet contains ITraceDataCollectors, then the NumberOfBuffers will be updated to reflect the number of buffers that ETW is using for its tracing session. In this case, the value of the NumberOfBuffers can be different than what the client originally had specified, but will be greater than or equal to the value of the MinimumBuffers property, and less than or equal to the value of the MaximumBuffers property.
<34> Section 3.2.4.15.7: On Windows, the IDataCollectorCollection::AddRange method will return an error that is defined in section 2.2.1 or [MS-ERREF] section 2.1.
<35> Section 3.2.4.16.8: The Windows implementation of the Performance Logs and Alerts Protocol uses either the file system or the task schedule as a persistent store.
<36> Section 3.2.4.17: Although this protocol does not specify any values for key, the Windows implementation does have certain reserved values for key. For the Level value map, the reserved key values are listed below. They are given with respect to the property on an event, and how an ETW controller would use it:
|
Value |
Usage |
|---|---|
|
win:LogAlways |
Event: Events with this level are always be written to ETW. Controller: Specifies this level when interested in events of all possible levels. |
|
win:Critical |
Event: Indicates a state change that requires immediate attention. Controller: Specifies this level when only interested in events of this level. |
|
win:Error |
Event: Indicates a transition to an errors state. Controller: Specifies this level when interested in events which have the following level: win:Error and win:Critical. |
|
win:Warning |
Event: Indicates a condition which could require attention. Controller: Specifies this level when interested in events which have the following levels: win:Warning, win:Error, and win:Critical. |
|
win:Informational |
Event: Conveys information which could be of interest. Controller: Specifies this level when interested in events which have the following levels: win:Informational, win:Warning, win:Error, and win:Critical. |
|
win:Verbose |
Event: Conveys very detailed state information. Controller: Specifies this level when interested in events which have the following levels: win:Verbose, win:Informational, win:Warning, win:Error, and win:Critical. |
|
win:ReservedLevel6 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel7 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel8 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel9 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel10 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel11 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel12 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel13 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel14 |
This level is reserved for use on future Windows versions. |
|
win:ReservedLevel15 |
This level is reserved for use on future Windows versions. |
The following table lists the values used for KeywordsAll and KeywordsAny, along with their semantic meaning:
|
Value |
Description |
|---|---|
|
win:AnyKeyword |
This keyword is used when no other keyword is specified, either on an event or by the controller. |
|
win:Reserved |
This keyword is reserved for use on future Windows versions. |
|
win:WDIContext |
This keyword refers to context events which are raised by the Windows Diagnostic Infrastructure. |
|
win:WDIDiag |
This keyword refers to diagnostic events which are raised by the Windows Diagnostic Infrastructure. |
|
win:SQM |
This keyword refers to events which are directed to the Windows Software Quality Metric infrastructure. |
|
win:AuditFailure |
This keyword refers to failed security audit events. |
|
win:AuditSuccess |
This keyword refers to successful security audit events. |
|
win:CorrelationHint |
This keyword is used to correlate several events together. |
|
win:EventlogClassic |
This keyword refers to events which are directed to the Eventlog mechanism which existed prior to Windows Vista. |
|
win:ReservedKeyword56 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword57 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword58 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword59 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword60 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword61 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword62 |
This level is reserved for use on future Windows versions. |
|
win:ReservedKeyword63 |
This level is reserved for use on future Windows versions. |
<37> Section 3.2.4.17: The following table shows the range of valid values for this property, depending on what the ValueMapItem represents:
|
Type |
Range of Values |
|---|---|
|
Level |
0x00 - 0xFF |
|
KeywordsAny |
0x00000000 - 0XFFFFFFFF |
|
KeywordsAll |
0x00000000 - 0xFFFFFFFF |
The Microsoft implementation of the Performance Logs and Alerts Protocol has reserved values for Level, KeywordsAny and KeywordsAll. The following tables list the values of the reserved fields for the levels and keywords (both KeywordsAny and KeywordsAll):
|
Level Name |
Value |
|---|---|
|
win:LogAlways |
0x00000000 |
|
win:Critical |
0x00000001 |
|
win:Error |
0x00000002 |
|
win:Warning |
0x00000003 |
|
win:Informational |
0x00000004 |
|
win:Verbose |
0x00000005 |
|
win:ReservedLevel6 |
0x00000006 |
|
win:ReservedLevel7 |
0x00000007 |
|
win:ReservedLevel8 |
0x00000008 |
|
win:ReservedLevel9 |
0x00000009 |
|
win:ReservedLevel10 |
0x0000000A |
|
win:ReservedLevel11 |
0x0000000B |
|
win:ReservedLevel12 |
0x0000000C |
|
win:ReservedLevel13 |
0x0000000D |
|
win:ReservedLevel14 |
0x0000000E |
|
win:ReservedLevel15 |
0x0000000F |
|
Keyword Name |
Value |
|---|---|
|
win:AnyKeyword |
0x0000000000000000 |
|
win:Reserved |
0x0001000000000000 |
|
win:WDIContext |
0x0002000000000000 |
|
win:WDIDiag |
0x0004000000000000 |
|
win:SQM |
0x0008000000000000 |
|
win:AuditFailure |
0x0010000000000000 |
|
win:AuditSuccess |
0x0020000000000000 |
|
win:CorrelationHint |
0x0040000000000000 |
|
win:EventlogClassic |
0x0080000000000000 |
|
win:ReservedKeyword56 |
0x0100000000000000 |
|
win:ReservedKeyword57 |
0x0200000000000000 |
|
win:ReservedKeyword58 |
0x0400000000000000 |
|
win:ReservedKeyword59 |
0x0800000000000000 |
|
win:ReservedKeyword60 |
0x1000000000000000 |
|
win:ReservedKeyword61 |
0x2000000000000000 |
|
win:ReservedKeyword62 |
0x4000000000000000 |
|
win:ReservedKeyword63 |
0x8000000000000000 |
<38> Section 3.2.4.19: The Microsoft implementation of the Performance Logs and Alerts Protocol does not require that element placement follow a strict XSD. The Microsoft implementation of the protocol, when looking for a specific element, is not concerned with where that element is specified in the overall XML document. For example, when looking for the element TraceDataProvider, the Microsoft implementation is not concerned with what elements could be before it or after it; it also ensures that the TraceDataProvider element is within the scope of its parent, which is the TraceDataCollector element. Therefore, several elements can be before and/or after the TraceDataProvider element, all within the scope of the TraceDataCollector element, that would not pass the strict validation of an XSD but is acceptable to the Microsoft implementation of the Performance Logs and Alerts Protocol.