About BMC OEM log(Windows 11)

Question

About BMC OEM log(Windows 11)

Garfield Chien 0

Dear Microsoft Support Team,

We are currently investigating several OEM-specific IPMI System Event Log (SEL) records observed on a system running Windows 11.

The following raw SEL records were retrieved from the BMC:

0x03 0x00 0xdf 0x20 0x30 0xa9 0x6a 0x37 0x01 0x00 0x09 0x00 0x00 0x00 0x20 0x00
0x05 0x00 0xc0 0x20 0x30 0xa9 0x6a 0x37 0x01 0x00 0x29 0x00 0x00 0x00 0x00 0x00
0x06 0x00 0xc0 0x20 0x30 0xa9 0x6a 0x37 0x01 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x07 0x00 0xd0 0x20 0x30 0xa9 0x6a 0x37 0x01 0x00 0x0c 0x00 0x00 0x00 0x00 0x00
0x08 0x00 0xc0 0x20 0x30 0xa9 0x6a 0x37 0x01 0x00 0x80 0xe6 0xa1 0xdf 0x07 0x45

Based on the IPMI specification, these records appear to be OEM-specific SEL records, with record types 0xC0, 0xD0, and 0xDF.

We would appreciate your assistance in clarifying the following:

Does Windows 11 or any Microsoft component define or generate these OEM-specific IPMI SEL records?

If these records are Microsoft-defined, could you provide the corresponding decoding specification or technical documentation?

Could you clarify the meaning of each record type and its associated event data?

Is there any Microsoft-provided tool or reference implementation available for decoding these records?

Our goal is to implement the appropriate decoding mechanism in our BMC firmware so that these events can be displayed with meaningful descriptions.

Any technical documentation or guidance would be greatly appreciated.

Thank you for your assistance.

Best regards,

0 comments

3 answers

Your answer

Answer 1

Welcome to Microsoft Q&A!

Thank you for providing the raw SEL records and for clarifying that you are working on BMC firmware development.

The manufacturer bytes 37 01 00 represent Microsoft's IANA enterprise ID, 0x000137. Windows boot components, including Boot Manager, Winload and the early Windows kernel, can generate Microsoft OEM SEL records during the boot process.

At a high level, the record types are used as follows:

0xC0, OEM raw-data record: Contains up to six bytes of supplemental or raw event data. Its interpretation depends on the associated leading event record, so it generally cannot be decoded reliably on its own.
0xD0, OEM error record: Contains a Microsoft-defined error code and status value, with the status typically representing an NTSTATUS value. Additional event data may be provided through associated 0xC0 records.
0xDF, OEM boot-environment record: Used by Windows boot-environment components for startup-related diagnostic or event information. The six-byte payload is interpreted according to Microsoft-defined boot-event values.

For example, the 0xD0 record you provided contains:

Microsoft IANA ID: 37 01 00
Error code: 0x000C
Status value: 0x00000000

However, I would recommend against interpreting the exact meaning of error code 0x000C, the 0xDF event value, or the associated 0xC0 payloads based solely on the raw bytes. Their meanings depend on Microsoft-defined values and, in some cases, the relationship between adjacent SEL records.

Microsoft provides public documentation for Windows IPMI-related structures, but a complete public decoding table or supported reference decoder for these Microsoft OEM SEL payloads does not appear to be available. Standard IPMI utilities may retrieve and display the raw records, but meaningful decoding requires the corresponding Microsoft-specific definitions.

For a production BMC implementation, I would also recommend avoiding hard-coded descriptions derived only from observed records. Without an authoritative specification, there is a risk of interpreting an event incorrectly or relying on definitions that could change.

Since your requirement is specifically for BMC firmware development and may involve a non-public hardware interface specification, the best approach would be to contact Microsoft through the Windows Hardware Developer Program:

Sign in with a Partner Center account enrolled in the Windows Hardware Program.
Open a support case through Microsoft Engage Center.
Select Windows Developer Center as the product.
Select Hardware Device Drivers as the problem type.
Provide the raw SEL records, Windows version and build, BMC/firmware information, reproduction details, and explain that you require the OEM SEL decoding specification for implementation in BMC firmware.

If your organization does not currently have access to an enrolled Windows Hardware Program account, you can contact Partner Center support regarding enrollment or the appropriate hardware support channel.

If your organization already works directly with Microsoft as a hardware or device partner, I would also recommend reaching out through your existing Microsoft Device Partner or OEM engineering contact. They should be able to advise whether the specification can be provided and whether any additional agreements are required.

In summary, these records can be generated by Microsoft Windows boot components, but the complete event-code and payload mappings are Microsoft-specific and are not defined by the general IPMI specification. For an authoritative decoding specification suitable for a BMC firmware implementation, the Windows Hardware Program or your Microsoft hardware/OEM engineering contact would be the appropriate path.

References:

I hope this helps clarify both the SEL records and the appropriate next step for obtaining the decoding information.

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.

Answer 2

Garfield Chien 0

Thank you for your detailed explanation.

As a BMC firmware developer, we would like to implement the decoding of these OEM-specific SEL records (0xC0, 0xD0, and 0xDF) so that meaningful event descriptions can be displayed in the BMC event log.

Could you please advise how we can contact the appropriate Microsoft hardware or driver support team to obtain the OEM SEL record decoding specification?

If this specification is not publicly available, is there an official support channel through which hardware vendors can request it?

Thank you for your assistance.

0 comments

Answer 3

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:

Offset	Example	Interpretation
0–1	`03 00`	SEL record ID, little-endian
2	`DF`	OEM record type
3–6	`20 30 A9 6A`	Timestamp, little-endian
7–9	`37 01 00`	Manufacturer/IANA enterprise ID: `0x000137`
10–15	`09 00 00 00 20 00`	Six bytes of OEM-defined event data

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:

Record ID	Type	Manufacturer	OEM event bytes
`0x0003`	`0xDF`	`0x000137`	`09 00 00 00 20 00`
`0x0005`	`0xC0`	`0x000137`	`29 00 00 00 00 00`
`0x0006`	`0xC0`	`0x000137`	`00 00 00 00 00 00`
`0x0007`	`0xD0`	`0x000137`	`0C 00 00 00 00 00`
`0x0008`	`0xC0`	`0x000137`	`80 E6 A1 DF 07 45`

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:

Parse offsets 0–9 using the standard timestamped OEM SEL layout.
Dispatch decoding by the three-byte manufacturer ID.
Preserve 0xC0, 0xD0, and 0xDF payloads as raw hexadecimal unless a Microsoft-provided specification is obtained.
Do not infer descriptions from the internal enum ordering; no public mapping establishes that relationship.
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