Export (0) Print
Expand All

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 released service packs:

  • 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

Exceptions, if any, are noted below. If a service pack or Quick Fix Engineering (QFE) number appears with the product version, behavior changed in that service pack or QFE. The new behavior also applies to subsequent service packs of the product 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 3.1.1.12: In Windows based server implementation, the server leverages the context handle table provided by RPC. For more information about RPC context handles, see [MSDN-CH].

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

<6> 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.

<7> Section 3.1.4.8: In a Windows server-based implementation, 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 in this case.

<8> Section 3.1.4.8: In Windows server implementations, the server returns ERROR_EVT_INVALID_QUERY (0x00003A99) in this case.

<9> 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).

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

<11> 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 may potentially cause system issues.

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

<13> 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 may potentially cause system issues.

<14> 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, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2, 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.

<15> Section 3.1.4.12: In Windows, the server may omit the invalid channels.

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

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

<18> 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 [MS-EVEN6] specification. In that case, the server's behavior is undefined and may potentially cause system issues.

<19> 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 will 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. Windows 7, Windows Server 2008 R2, Windows 8, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2 will always return ERROR_INVALID_PARAMETER (0x00000057) when errors are encountered validating the pos parameter and will not change the cursor position.

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

<21> 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 may potentially cause system issues.

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

<23> 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.

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

<25> 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.

<26> 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.

<27> Section 3.1.4.17: In a Windows-based server implementation, the server returns any possible error code from the last errors set by CreateFile function [MSDN-CreateFile] if the method fails.

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

<29> Section 3.1.4.18: Windows may 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 may return ERROR_SUCCESS with the RpcInfo structure containing the error ERROR_EVT_MESSAGE_NOT_FOUND (0x00003AB3).

<30> Section 3.1.4.18: Windows may 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 may return ERROR_SUCCESS with the RpcInfo structure containing the error ERROR_EVT_MESSAGE_NOT_FOUND (0x00003AB3).

<31> Section 3.1.4.18: Server implementations on Windows return ERROR_INVALID_NAME when the logFilePath parameter is not valid for the underlying file system.

<32> Section 3.1.4.19: 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.

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

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

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

<36> Section 3.1.4.21: The FileMax property is only supported by Windows 7, Windows Server 2008 R2, Windows Server 2012, Windows 8.1, and Windows Server 2012 R2. 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 will be passed back unmodified by calls to EvtRpcPutChannelConfig on Windows 7, Windows Server 2008 R2, Windows Server 2012, Windows 8, Windows 8.1, or Windows Server 2012 R2.

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

<38> 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.

<39> 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.

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

<41> Section 3.1.4.22: In a Windows-based server implementation, 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.

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

<43> 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.

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

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

<46> 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.

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

<48> 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 may potentially cause system issues.

<49> Section 3.1.4.26: In a Windows-based server implementation, the server does not return an error in this case and sets nothing in the pubMetadataProps parameter.

<50> Section 3.1.4.26: A Windows implementation wraps the RPC calls with an API layer that may provide 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.

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

<52> 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 may potentially cause system issues.

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

<54> 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 may potentially cause system issues.

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

<56> 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.

<57> 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.

<58> Section 3.1.4.30: In a Windows-based server implementation, the server returns ERROR_INVALID_PARAMETER (0x00000057). When the path is NULL, the server returns any possible error codes a RegOpenKeyEx function could return.

<59> Section 3.1.4.31: For example, in the Windows implementation, substitution parameters are denoted by "%1", "%2", and so on. An event message may 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".

<60> 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 may potentially cause system issues.

<61> Section 3.1.4.31: In a Windows based server implementation, the server uses the FormatMessage function (see [MSDN-FMT]) to perform this task.

<62> Section 3.1.4.31: In a Windows based server implementation, the server uses the FormatMessage function (see [MSDN-FMT]) to perform this task.

<63> 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 may potentially cause system issues.

<64> 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 may potentially cause system issues.

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

<66> 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.

<67> Section 3.2.7: In a Windows-based client implementation, because the Windows Server keeps its 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, the Windows Server accepts the change and saves it. Otherwise, it reverts the registry change and discards the client's change.

 
Show:
© 2014 Microsoft