About BMC OEM log(Windows 11)

These records should be parsed as timestamped OEM SEL records, and the manufacturer bytes 37 01 00 identify Microsoft (0x000137, decimal 311); however, Microsoft does not publish a supported payload-decoding specification for record types 0xC0, 0xD0, or 0xDF.

Byte-level interpretation

For a 16-byte timestamped OEM SEL record:

Under the IPMI SEL format, 0xC0–0xDF are timestamped OEM record types. Their payload semantics are not assigned globally by IPMI; the organization identified by the manufacturer ID defines them.^1^

Applied to the supplied records:

The common manufacturer field is evidence that these records use a Microsoft-assigned OEM namespace. It does not, by itself, establish which Windows component wrote each record or provide enough information to assign descriptions to the final six bytes.

What Microsoft documents

Windows includes internal IPMI SEL support and defines categories such as WHEA, PCI hardware error, NMI, raw, driver, bug-check recovery, and bug-check data. However, the corresponding IPMI_OS_SEL_RECORD_TYPE enumeration is explicitly marked “Reserved for system use” and does not document how those internal categories map to outer IPMI record-type bytes or their six-byte payloads.^2^

The associated IPMI_OS_SEL_RECORD structure is also reserved for system use. It describes an internal record containing a type, length, and variable data buffer—not the public on-wire decoding of 0xC0, 0xD0, or 0xDF.^3^

Windows can interact with a BMC through its IPMI driver/provider, retrieve SEL data, and expose BMC information through management interfaces. Microsoft also notes that management access and interpretation can remain proprietary and require OEM tools.^4^

WHEA is separate from the outer SEL encoding: when Windows represents platform hardware errors as WHEA records, it uses the UEFI Common Platform Error Record (CPER) format.^5^ The six-byte OEM fields shown here are not complete CPER records, so they cannot be decoded directly with the published CPER structures.

Tooling and implementation guidance

There is no documented Microsoft reference decoder for these three OEM record types. Microsoft’s IPMI tooling can retrieve or transport SEL entries, but its published HLK IPMI test validates BMC operations rather than decoding proprietary OEM payloads.^6^

For the BMC firmware:

1. Parse offsets 0–9 using the standard timestamped OEM SEL layout.
2. Dispatch decoding by the three-byte manufacturer ID.
3. Preserve 0xC0, 0xD0, and 0xDF payloads as raw hexadecimal unless a Microsoft-provided specification is obtained.
4. Do not infer descriptions from the internal enum ordering; no public mapping establishes that relationship.
5. Request the private SEL contract through the Microsoft hardware/driver support channel used for the platform integration. Supply:
   • Windows 11 build and edition
   • Microsoft IPMI driver version
   • BMC vendor, model, and firmware
   • Complete SEL before and after a controlled trigger
   • Matching Windows System events, WHEA records, and bug-check data
   • Whether the entries occur during shutdown, crash recovery, hardware error, or normal boot

Until that specification is supplied, a safe display string is, for example, “Microsoft OEM SEL record, type 0xC0, data 29 00 00 00 00 00” rather than assigning an unverified event meaning.

References

1. System Event Log (SEL) | bougou/go-ipmi | DeepWiki
2. IPMI_OS_SEL_RECORD_TYPE - Windows drivers | Microsoft Learn
3. IPMI_OS_SEL_RECORD structure (ntddk.h)
4. Remote Hardware Management
5. Error Records
6. IPMI