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.

Windows Client

  • Windows NT Workstation 4.0 operating system with Service Pack 2 (SP2)

  • Windows 2000 Professional operating system

  • Windows XP operating system

  • Windows Vista operating system

  • Windows 7 operating system

  • Windows 8 operating system

  • Windows 8.1 operating system

  • Windows 10 operating system

  • Windows 11 operating system

Windows Server

  • Windows 2000 Server operating system

  • Windows Server 2003 operating system

  • Windows Server 2008 operating system

  • Windows Server 2008 R2 operating system

  • Windows Server 2012 operating system

  • Windows Server 2012 R2 operating system

  • Windows Server 2016 operating system

  • Windows Server operating system

  • Windows Server 2019 operating system

  • Windows Server 2022 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 1.6: On Windows Vista and later and Windows Server 2008 and later, the EventLog Remoting Protocol Version 6.0 specified in [MS-EVEN6] is preferred because of its additional functionality.

Note that the Windows client platforms can act as either a client or a server for this protocol. Similarly, applicable Windows Server releases can also act as either a client or a server for this protocol.

<2> Section 1.8.1: Windows only uses the values in [MS-DTYP].

<3> Section 1.8.2: Windows does not prefix the names of the event logs it creates. In addition, Windows implementations impose the following limitations on event log names: They are treated in a case-insensitive manner, they are limited to 200 characters (400 bytes if Unicode is used), and they do not begin with the character '\'. Windows does not verify the collision of the event log names in the same server. This is prevented by the Windows registry. The Windows registry does not allow duplicate keys.

<4> Section 1.8.3: Windows does not prefix the names of the event sources it creates. In addition, Windows implementations impose the following limitations on event source names: They are treated in a case-insensitive manner, they are limited to 200 characters (400 bytes if Unicode is used), and they do not begin with the character '\'. Windows does not verify the collision of the event log names in the same server. This is prevented by the Windows registry. The Windows registry does not allow duplicate keys.

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

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

<7> Section 2.2.2: The event sources that write to the Windows security log use the EVENTLOG_AUDIT_SUCCESS and EVENTLOG_AUDIT_FAILURE types exclusively, whereas event sources that write to other logs use the other four types exclusively.

<8> Section 2.2.3: Windows sends NetBIOS names, as specified in [MS-SMB].

<9> Section 2.2.3: The 32-bit Windows machines use zero bytes of padding. The 64-bit Windows machines use a number of bytes of padding needed to make the end of this field be on an 8-byte boundary from the beginning of the structure.

<10> Section 2.2.10:  For information on how Windows converts between Unicode and ANSI strings, see [MSDN-ANSI] and [MSDN-TRANS].

<11> Section 3: The NDR consistency check is at target level 5.0 (Windows versions earlier than Windows Vista) or target level 6.0 (Windows Vista), as specified in [MS-RPCE] section 3.1.1.5.3.2.2.2.

<12> Section 3.1.1.2: The CustomSD value is not supported in Windows XP, Windows 2000 Professional, and Windows NT Workstation 4.0 SP2. Applicable Windows Server releases can use the ConvertStringSecurityDescriptorToSecurityDescriptor function to check if the value is valid; for more information see [MSDN-CNVTSTRGSDTSD].

<13> Section 3.1.1.4:  In Windows, the EventID is mapped to a description related to the event by using a separate file, where the file is specific to the event source. As specified in section 3.1.1.3, it is possible to write events under event sources that do not exist in the registry. If the EventID is relative to an event source that does not exist in the registry, any clients that are reading events will not be able to find a description for any of the EventIDs.

The EventID layout is used by other operating system components besides the event log. Because of this, the layout used by Windows has some additional structure (for example, a Facility field and a Code field) that is not used by the event log and that can be ignored in this context.

<14> Section 3.1.4: If ElfrChangeNotify is called remotely, applicable Windows Server releases typically return STATUS_INVALID_HANDLE, as specified in [MS-ERREF].

<15> Section 3.1.4.1: Applicable Windows Server releases do not use a specific flag to indicate whether an event log file is a backup file or not. This means that a check for a backup event log file is a check that the file is a correctly formatted event log file.

<16> Section 3.1.4.1: In Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008, failures other than checks on the BackupFileName parameter erroneously return STATUS_SUCCESS (0x00000000) with LogHandle set to NULL.

<17> Section 3.1.4.2: In Windows XP, Windows Server 2003, Windows Vista, and Windows Server 2008, failures other than checks on the BackupFileName parameter erroneously return STATUS_SUCCESS (0x00000000) with LogHandle set to NULL.

<18> Section 3.1.4.3: The server has an access control list (ACL) that is used to control access to the log. The protocol does not have any methods for reading or setting that ACL.

<19> Section 3.1.4.7:  In applicable Windows Server releases, the server checks if the signature is the correct value (as specified in section 3.1.1.5).

<20> Section 3.1.4.9: In Windows Vista and later and Windows Server 2008 and later, the methods do not differentiate between handles for event log files and handles for backup event log files. These methods return STATUS_SUCCESS when called with a handle obtained from ElfrOpenBELA (section 3.1.4.2) or ElfrOpenBELW (section 3.1.4.1).

<21> Section 3.1.4.9: Applicable Windows Server releases check the flags field of IELF_HANDLE (section 3.1.1.5).

<22> Section 3.1.4.9: UNC paths can only be used as BackupFileName for Windows NT Workstation 4.0 SP2 and Windows 2000 operating system.

<23> Section 3.1.4.9: ElfrClearELFW (Opnum 0) will erroneously return STATUS_SUCCESS if the buffer inside BackupFileName is NULL in Windows XP and later and Windows Server 2003 and later. The ElfrClearELFA method returns a nonzero value (0xC000003A STATUS_OBJECT_PATH_NOT_FOUND).

<24> Section 3.1.4.9: In applicable Windows Server releases, the LastRecordRead field of the log context handle as defined in section 3.1.1.5 is modified to 0 so that the next record ID starts from 1.

<25> Section 3.1.4.11: Applicable Windows Server releases return ERROR_PRIVILEGE_NOT_HELD (0x00000522) if the user does not have the backup privilege.

<26> Section 3.1.4.12: In Windows Server 2003 and Windows XP a STATUS_ACCESS_DENIED error will be received.

<27> Section 3.1.4.13:  Not supported in Windows NT 4.0 operating system Service Pack 2 (SP2), Windows 2000, Windows Server 2003, and Windows XP.

<28> Section 3.1.4.13: Applicable Windows Server releases do not check the Time value and the EventType.

<29> Section 3.1.4.13: Applicable Windows Server releases use the IsValidSid function (described in [MSDN-IsValidSid]) to check the validity of the SID.

<30> Section 3.1.4.13: In Windows Vista and later and Windows Server 2008 and later, the server does not set these values. Thus, they retain the values set by the client.

<31> Section 3.1.4.14: The API is not intended to support dynamically changing computer names. Current implementations of Windows cache the ComputerName parameter the first time a client calls the API, and use that name on subsequent calls until the machine is rebooted.

<32> Section 3.1.4.15: This method is supported only on Windows Server 2003 R2 operating system.

<33> Section 3.1.4.16:  The ElfrReportEventExW method is not implemented in Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1.

<34> Section 3.1.4.16:  In Windows, the system time at event generation can be obtained using the GetSystemTimePreciseAsFileTime method described in [MSDN-PreciseSysTme].

<35> Section 3.1.4.16: In applicable Windows Server releases, the server does not check the TimeGenerated and EventType values.

<36> Section 3.1.4.17:  The ElfrReportEventExA method is not implemented in Windows 2000, Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1.

<37> Section 3.1.4.18:  In applicable Windows Server releases, the number of records is stored in the header of the event log file.

<38> Section 3.1.4.19:  In applicable Windows Server releases, the oldest record number is stored in the header of the event log file.

<39> Section 3.1.4.21: Applicable Windows Server releases will always close the handle as long as they can find the handle in their internal table. This occurs even if the handle is not from the ElfrOpenELW (section 3.1.4.3) method, the ElfrOpenELA (section 3.1.4.4) method, the ElfrOpenBELW (section 3.1.4.1) method, or the ElfrOpenBELA (section 3.1.4.2). If the server closes a handle that is not from one of these methods, it can cause the client application to behave in an unexpected way. It is the caller’s responsibility to make sure they are passing the right handle to this method.

<40> Section 3.1.4.21: Applicable Windows Server releases free the memory of IELF_HANDLE (as specified in section 3.1.1.5) and returns success.

<41> Section 3.1.4.22: Applicable Windows Server releases do not check whether the passing handle comes from the ElfrRegisterEventSourceW (section 3.1.4.5) method or the ElfrRegisterEventSourceA (section 3.1.4.6) method.

<42> Section 3.1.4.23: Windows implementations typically return STATUS_INVALID_HANDLE or STATUS_INVALID_PARAMETER, as specified in [MS-ERREF] section 2.3.

<43> Section 3.2.4: This method is not supported on Windows NT operating system, Windows 2000, Windows Server 2003 prior to Windows Server 2003 R2, or Windows XP. If ElfrChangeNotify is called remotely, applicable Windows Server releases typically return STATUS_INVALID_HANDLE, as specified in [MS-ERREF].

<44> Section 3.2.4.1.1: In Windows client implementations, these are not read for the Security log due to that subkey's highly restrictive permissions; in this case, the log name is a resource in the Event Viewer application.

<45> Section 3.2.4.1.1: Based on knowledge of client preferred locales, Windows client implementations often try to load a resource string from an alternate resource library location. Windows client implementations for Windows NT 4.0 SP2, Windows 2000, Windows Server 2003, and Windows XP append a numeric locale identifier (LCID) such as "409" to the file path and a ".mui" extension to the file name. Windows Vista and later and Windows Server 2008 and later insert a language name such as "en-us". In either case, Windows falls back to the original file path if the language-specific file is not found. For more information on locale identifiers and language names, see [MS-LCID].

<46> Section 3.2.4.1.2: In Windows client implementations, these are not read for the Security log because of the subkey's highly restrictive permissions; in this case, the log name is a resource in the Event Viewer application.

<47> Section 3.2.4.1.2: Based on knowledge of client-preferred locales, Windows client implementations can try to load a resource string from an alternate resource library location. Windows client implementations for Windows NT 4.0 SP2, Windows 2000, Windows Server 2003, and Windows XP can append a numeric locale identifier (LCID) such as "409" to the file path and a ".mui" extension to the file name. Windows Vista and later and Windows Server 2008 and later insert a language name such as "en-us". In either case, Windows falls back to the original file path if the language-specific file is not found. For more information about locale identifiers and language names, see [MS-LCID].

<48> Section 3.2.4.1.3: In Windows client implementations, these are not read for the Security log because of the highly restrictive permissions for that subkey; in this case, the log name is a resource in the Event Viewer application.

<49> Section 3.2.4.1.3: In Windows client implementations, these are not read for the Security log because of the highly restrictive permissions for that subkey; in this case, the log name is a resource in the Event Viewer application.

<50> Section 3.2.4.1.3: Based on knowledge of client-preferred locales, Windows client implementations can try to load a resource string from an alternate resource library location. Windows client implementations for Windows NT 4.0 SP2, Windows 2000, Windows Server 2003, and Windows XP can append a numeric locale identifier (LCID) such as "409" to the file path and an ".mui" extension to the file name. Windows Vista and later and Windows Server 2008 and later insert a language name such as "en-us". In either case, Windows falls back to the original file path if the language-specific file is not found. For more information about locale identifiers and language names, see [MS-LCID].

<51> Section 3.2.4.1.4: In Windows client implementations, these are not read for the Security log due to that subkey's highly restrictive permissions; in this case, the log name is a resource in the Event Viewer application.

<52> Section 3.2.4.1.4: Based on knowledge of client-preferred locales, Windows client implementations try to load a resource string from an alternate resource library location. Windows client implementations for Windows NT 4.0 SP2, Windows 2000, Windows Server 2003, and Windows XP append a numeric locale identifier (LCID) such as "409" to the file path and a ".mui" extension to the file name. Windows Vista and later and Windows Server 2008 and later insert a language name such as "en-us". In either case, Windows falls back to the original file path if the language-specific file is not found. For more information on locale identifiers and language names, see [MS-LCID].

<53> Section 3.2.4.1.5: The replacement behavior is not exactly recursive, although it is very similar to recursive behavior. Consider the unexpanded description string "%1%2" where the first EventLogRecord.String is "%". This becomes "%%2", which is a parameter insertion, and the second EventLogRecord.String is never retrieved.

<54> Section 3.2.4.1.5: The number of substitutions in Windows implementations is capped at 100.

<55> Section 3.2.4.1.5.3: Expanding SIDs: Starting with Windows 2000, Windows client implementations attempt to look up the name of the security principal for a properly formatted SID. The lookup is first attempted on the event source server, and, if that fails, it is attempted in the Global Catalog server for the forest to which the event source server belongs. For information on how to implement this lookup, see [MS-LSAD] and [MS-LSAT].

Expanding GUIDs: Starting with Windows 2000, Windows client implementations attempt to find the name of the Active Directory object with this GUID. First, the client implementations attempt to look this up as a well-known schema GUID (for example, Administrators). Then, the client implementations look for an object by this name on the domain controller (DC) in the same domain as the target computer. Finally, they look for an object by this name on the Global Catalog for the local domain. If the client implementations still have not succeeded, they leave the GUID string in the output as is. For information on implementing this lookup, see [RFC2251] and [MS-ADTS].

<56> Section 3.2.4.1.5.4: As a fallback, Windows Event Viewer for SKUs later than Windows XP tries to resolve the "%systemroot%" and "%systemdrive%" environment variables by reading the local registry value "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion" when it fails to read the remote server registry for the same value.