7 Appendix B: Product Behavior

  • Article

The information in this specification is applicable to the following Microsoft products or supplemental software. References to product versions include updates to those products.

The terms "earlier" and "later", when used with a product version, refer to either all preceding versions or all subsequent versions, respectively. The term "through" refers to the inclusive range of versions. Applicable Microsoft products are listed chronologically in this section.

The following tables show the relationships between Microsoft product versions or supplemental software and the roles they perform.

Windows Client

Client role

Server role

Windows Vista operating system

Yes

Yes

Windows 7 operating system

Yes

Yes

Windows 8 operating system

Yes

Yes

Windows 8.1 operating system

Yes

Yes

Windows 10 operating system

Yes

Yes

Windows 11 operating system

Yes

Yes

Windows Server

Client role

Server role

Windows Server 2008 operating system

Yes

Yes

Windows Server 2008 R2 operating system

Yes

Yes

Windows Server 2012 operating system

Yes

Yes

Windows Server 2012 R2 operating system

Yes

Yes

Windows Server 2016 operating system

Yes

Yes

Windows Server operating system

Yes

Yes

Windows Server 2019 operating system

Yes

Yes

Windows Server 2022 operating system

Yes

Yes

Windows Server 2025 operating system

Yes

Yes

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 1.8.1: Windows prefixes the names of some of the channels it creates with the string Microsoft-Windows-. For more information, see [MSDN-EVENT].

<2> Section 1.8.2: Windows prefixes the names of some of the publishers it creates with the string Microsoft-Windows-. For more information, see [MSDN-EVENTS].

<3> Section 1.8.4: Windows uses only the values specified in [MS-ERREF] section 2.3.

<4> Section 2.1.1: For more information about the significance of packet-level authentication, see Windows NTLM Elevation of Privilege Vulnerability security update June 2021 [MSFT-CVE-2021-31958]. Applies to all versions of client and server, Windows Vista operating system and Windows Server 2008 operating system and later.

<5> Section 2.1.2: For more information about the significance of packet-level authentication, see Windows NTLM Elevation of Privilege Vulnerability security update June 2021 [MSFT-CVE-2021-31958]. Applies to all versions of client and server, Windows Vista and Windows Server 2008 and later.

<6> Section 2.2.16: Windows 10 v1703 operating system and earlier ignore the Target attribute.

<7> Section 3.1.1.12: In applicable Windows Server releases, the server leverages the context handle table provided by RPC. For more information about RPC context handles, see [MSDN-CH].

<8> Section 3.1.4: All errors are as specified in [MS-ERREF] section 2.3.

<9> Section 3.1.4.7.2:  In a Windows implementation, the event definition is part of a compiled binary image, and as such is external to this protocol.

<10> Section 3.1.4.8: In applicable Windows Server releases, the server returns ERROR_NOT_FOUND (0x00000490) when the bookmark is invalid and the EvtSubscribeStrictrestrict flag is set. The server does not return an error if the bookmark is invalid and the EvtSubscribeStrict flag is not set. The server ignores the bookmark parameter.

<11> Section 3.1.4.8: In applicable Windows Server releases, the server returns ERROR_EVT_INVALID_QUERY (0x00003A99).

<12> Section 3.1.4.8: In Windows, if query parameter is not null the server will attempt to determine if the channel is valid. If the channel string contains one or more invalid characters (any character whose ASCII value is less than 32 or character '<', '>', '|', '\', '"', ':', ''', '*', '?'), the server will return ERROR_EVT_INVALID_CHANNEL_PATH (0x00003A98). If the channel does not exist, the server will return ERROR_EVT_CHANNEL_NOT_FOUND (0x00003A9F). If the channel is valid, and the non-null query parameter is invalid, the server will return ERROR_EVT_INVALID_QUERY (0x00003A99).

<13> Section 3.1.4.9: Windows Vista and Windows Server 2008 ignore this flags field.

<14> Section 3.1.4.9: In Windows, the server does not do a thorough validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space, and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. As such, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and could potentially cause system issues.

<15> Section 3.1.4.10: Windows Vista and Windows Server 2008 ignore this flags field.

<16> Section 3.1.4.11: In Windows, the server does not do a thorough validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space, and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. As such, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and could potentially cause system issues.

<17> Section 3.1.4.12: In Windows Vista and Windows Server 2008, the server does not validate the flags. It ignores any unrecognized flags, assumes that the path is a file if not specified, and iterates from oldest to newest if a direction flag is unspecified.

In Windows 7 and later and Windows Server 2008 R2 operating system and later, the server does not completely validate the flags. It does not return an error when neither the EvtQueryChannelPath nor EvtQueryFilePath bits are set, and does not return an error when neither the 0x00000100 nor 0x00000200 bits are set. The server assumes that the path is a file if not specified, and iterates from oldest to newest if a direction flag is not specified.

<18> Section 3.1.4.12: In Windows, the server can omit the invalid channels.

<19> Section 3.1.4.13: Windows limits the numRequestedRecords to 1024. If numRequestedRecords is greater than 1024, ERROR_INVALID_PARAPMETER is returned.

<20> Section 3.1.4.13: Windows Vista and Windows Server 2008 ignore this flag.

<21> Section 3.1.4.13: In Windows, the server does not do a thorough validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space and that the pointer points to a buffer that states the correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. As such, it is possible to circumvent the server, especially if the handle has been obtained from a different method in the EventLog Remoting Protocol Version 6. In that case, the server's behavior is undefined and can potentially cause system issues.

<22> Section 3.1.4.14: In the Windows implementation, the sign of the pos parameter is validated against the seek direction by the server. Windows Vista and Windows Server 2008 return ERROR_NOT_FOUND (0x00000490) in the above cases if the EvtSeekStrict flag is set. If the EvtSeekStrict flag is not set, Windows Vista and Windows Server 2008 will not return an error in the two cases above. In Windows Vista and Windows Server 2008, if the EvtSeekRelativeToFirst flag is set and the pos parameter has a negative value, the cursor of the result set remains at the first record. If the EvtSeekRelativeToLast flag is set and the pos parameter has a positive value, the cursor remains at the last record.

Except for Windows Vista and Windows Server 2008, Windows always returns ERROR_INVALID_PARAMETER (0x00000057) when errors are encountered validating the pos parameter and will not change the cursor position.

<23> Section 3.1.4.15: For more information on attributes, see [MSDN-FILEATT].

<24> Section 3.1.4.15: In Windows, the server does not do a thorough validation of the handle. It verifies that the handle can be transformed into a pointer in the appropriate address space, and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. As such, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<25> Section 3.1.4.16: Windows Vista and Windows Server 2008 ignore this flags field.

<26> Section 3.1.4.16: In the case of the failure of an internal function about which Windows doesn't receive detailed error information, it will fill the sub-error fields with 0xFFFFFFFF, which is often used as a generic error return code.

<27> Section 3.1.4.16: In applicable Windows Server releases, the server uses the CreateFile function [MSDN-CreateFile] to create the backup file and return any error code the CreateFile function can possibly set to the last error code when it fails.

<28> Section 3.1.4.17: In the Windows implementation, the client API layer typically validates the flags, and the server does not. Therefore, the onus is on the RPC client either to validate flags or to restrict support to valid flag combinations.

<29> Section 3.1.4.17: In Windows Vista and Windows Server 2008, the server does not validate the flags. It will ignore any unrecognized flags; and will assume that the path is a file if not specified.

<30> Section 3.1.4.17: In applicable Windows Server releases, the server returns any possible error code from the last errors set by CreateFile function [MSDN-CreateFile] if the method fails.

<31> Section 3.1.4.18: Windows Vista and Windows Server 2008 ignore this flags field.

<32> Section 3.1.4.18: Windows can erroneously return ERROR_SUCCESS. In such cases, the fields of the RpcInfo structure "error" will be set to nonzero values to specify the detail error. For example, the function EvtRpcLocalizeExportLog can return ERROR_SUCCESS with the RpcInfo structure containing the error ERROR_EVT_MESSAGE_NOT_FOUND (0x00003AB3).

<33> Section 3.1.4.18: Windows can erroneously return ERROR_SUCCESS. In such cases, the fields of the RpcInfo structure "error" will be set to nonzero values to specify the detail error. For example, the function EvtRpcLocalizeExportLog can return ERROR_SUCCESS with the RpcInfo structure containing the error ERROR_EVT_MESSAGE_NOT_FOUND (0x00003AB3).

<34> Section 3.1.4.18: Applicable Windows Server releases return ERROR_INVALID_NAME when the logFilePath parameter is not valid for the underlying file system.

<35> Section 3.1.4.19: In the case of the failure of an internal function about which Windows does not receive detailed error information, it will fill the sub-error fields with 0xFFFFFFFF, which is often used as a generic error return code.

<36> Section 3.1.4.19: Windows Vista and Windows Server 2008 ignore this flags field.

<37> Section 3.1.4.20: Windows Vista and Windows Server 2008 ignore this flags field.

<38> Section 3.1.4.21: Windows Vista and Windows Server 2008 ignore this flags field.

<39> Section 3.1.4.21: The FileMax property is not supported by Windows Vista and Windows Server 2008. Windows Vista and Windows Server 2008 call EvtRpcGetChannelConfig to receive the EvtRpcVariantList structure. FileMax is ignored by Windows Vista and Windows Server 2008. The value of FileMax received in the EvtRpcVariantList structure is passed back unmodified by calls to EvtRpcPutChannelConfig on Windows 7 and later and Windows Server 2008 R2 and later.

<40> Section 3.1.4.22: In Windows Vista and Windows Server 2008, the server does not validate the flag.

<41> Section 3.1.4.22: Windows based implementations of this protocol use the ControlGuid property to identify the WPP provider, a special publisher that is used to log debugging events. The WPP provider is not intended for general use. See [MSDN-WPPST] for more information about this publisher.

<42> Section 3.1.4.22: Windows will erroneously return ERROR_SUCCESS. In such cases the fields of the RpcInfo structure "error" will be set to nonzero values.

<43> Section 3.1.4.22: Applicable Windows Server releases do not check whether the publisher is already registered in the publisher table and will return ERROR_SUCCESS for unregistered publishers.

<44> Section 3.1.4.22: In applicable Windows Server releases, the initial value for BufferSize is 64k. Initial MinBuffers value is twice the number of processors of the system. Initial MaxBuffers value is the MinBuffers value plus 22. The initial Latency value is 1 second. The initial clocktype value is 0 and the initial value for SIDType is 1.

<45> Section 3.1.4.23: Windows Vista and Windows Server 2008 ignore this flags field.

<46> Section 3.1.4.23: In Windows, the server uses registry to implement the publisher table. The security descriptor for the publisher table is provided by the Windows registry system.

<47> Section 3.1.4.24: Windows Vista and Windows Server 2008 ignore this flags field.

<48> Section 3.1.4.25: Windows Vista and Windows Server 2008 ignore this flags field.

<49> Section 3.1.4.25: In Windows, the server uses a registry entry to save the publisher in the publisher table. The security descriptor for the publisher is the security descriptor for the registry entry.

<50> Section 3.1.4.26: Windows Vista and Windows Server 2008 ignore this flags field.

<51> Section 3.1.4.26: In Windows, the server does not do a complete validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. Therefore, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<52> Section 3.1.4.26: In applicable Windows Server releases, the server does not return an error in this case and sets nothing in the pubMetadataProps parameter.

<53> Section 3.1.4.26: A Windows implementation wraps the RPC calls with an API layer that provides default values for metadata that are not supplied by the publisher. For example, Windows provides a helplink based on the executable name for a particular provider if that provider does not supply a helplink.

<54> Section 3.1.4.27: Windows Vista and Windows Server 2008 ignore this flags field.

<55> Section 3.1.4.27: In Windows, the server does not do a thorough validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space, and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. Therefore, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<56> Section 3.1.4.28: Windows Server 2008 does not validate this flag.

<57> Section 3.1.4.28: In Windows, the server does not do a thorough validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space and that the pointer points to a buffer that states a correct handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. Therefore, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<58> Section 3.1.4.28: In Windows, the method does not fail when there is no metadata to return.

<59> Section 3.1.4.29: In Windows, the server does not validate the path parameter, and will start a new, partially configured channel or publisher registration if supplied with an invalid name.

<60> Section 3.1.4.30: In Windows, the server only validates that the path parameter is syntactically correct; it does not validate that the channel exists. The server returns ERROR_SUCCESS (0x00000000) if it is passed a channel name which is syntactically correct but nonexistent.

<61> Section 3.1.4.30: In applicable Windows Server releases, the server returns ERROR_INVALID_PARAMETER (0x00000057). When the path is NULL, the server returns any possible error codes a RegOpenKeyEx function could return.

<62> Section 3.1.4.31: In the Windows implementation, substitution parameters are denoted by "%1", "%2", and so on. An event message can be "Error number %1 occurred on disk drive %2." To format this message, the client could specify the eventId that denotes this event in the eventId parameter and supply the strings "5" and "C:" in the values parameter. If the client supplied a buffer that is large enough in the strings parameter, the server would set that buffer to "Error number 5 occurred on disk drive C".

<63> Section 3.1.4.31: In Windows, the server does not do a complete validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space and that the pointer points to a buffer that states a correct handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. Therefore, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<64> Section 3.1.4.31: In applicable Windows Server releases, the server uses the FormatMessage function (see [MSDN-FMT]) to perform this task.

<65> Section 3.1.4.31: In applicable Windows Server releases, the server uses the FormatMessage function (see [MSDN-FMT]) to perform this task.

<66> Section 3.1.4.33: In Windows, the server does not do a complete validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. Therefore, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<67> Section 3.1.4.34: In Windows, the server does not do a complete validation of the handle. It verifies that the handle can be transformed into a pointer in the proper address space and that the pointer points to a buffer that states a correct context handle type, and fails with ERROR_INVALID_PARAMETER (0x00000057) if the handle type does not match. Therefore, it is possible to circumvent the server, especially if the handle has been obtained from a different method in this specification. In that case, the server's behavior is undefined and can potentially cause system issues.

<68> Section 3.1.4.36: Windows implementations of this protocol use the GetThreadPreferredUILanguages function [MSDN-GETTHDPREUILANG] to determine the fallback locale.

<69> Section 3.1.4.36: In Windows Vista and Windows Server 2008, the server does not validate the flags parameter. The server responds to flags 0x0 and 0x100, and ignores all others.

<70> Section 3.2.7: In a Windows client implementation, because applicable Windows Server releases keep the publisher table in the registry, the client accesses the registry directly and finds the resource file location for a given publisher and changes the registry value directly. The resource file location is saved in the registry: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Publishers\<Publisher Identifier>\ResourceFileName". When the EvtRpcAssertConfig method (section 3.1.4.29) is issued, the server locates the same key, reads the ResourceFileName, and tries to open it. If the file can be opened, applicable Windows Server releases accept the change and save it. Otherwise, the registry change is reverted and the client's change is discarded.