Missing decode definitions for Product ID 0x036: PMC rev 2 / PMC_TRACE rev 1, reason 0x30010 (XMG NEO 15 E22)

Start by comparing the requested decode-defs/PMC/2/layout.csv and decode-defs/PMC_TRACE/1/layout.csv with the existing definitions and product mappings; the issue does not identify specific repository files or provide the record payloads. The key dependency is Intel confirmation or matching collateral for product 0x036. Done means the correct definitions and product mapping are available and these records decode beyond their headers.

Summary

On an XMG NEO 15 (E22) with an Intel Core i7-12700H and NVIDIA GeForce RTX 3080 Ti Laptop GPU, iclg v1.2.0 recognizes two Intel CrashLog records in a 3408-byte Windows WHEA CPER:

• Product ID 0x036, PMC revision 2, 2560 bytes
• Product ID 0x036, PMC_TRACE revision 1, 512 bytes
• Triage: CRASHLOG_REASON.PMC.30010H

Only the common headers are decoded; the tool reports missing definitions for both revisions. Could Intel confirm the product mapping, provide the corresponding collateral, and help interpret reason 0x30010 and the underlying records?

Hardware and failure history

• Laptop: XMG NEO 15 (E22), Tongfang platform.
• CPU: Intel Core i7-12700H (Alder Lake-H), with Intel integrated graphics.
• GPU: NVIDIA GeForce RTX 3080 Ti Laptop GPU.
• OS / collection: Windows; CPER saved from Microsoft-Windows-WHEA-Logger Event ID 1 (fatal hardware error), 3408 bytes, locally named largest-whea.cper.
• Storage relevant to the current investigation: Samsung SSD 980 1TB (system drive), plus a second SSD referred to as the NX drive.

There is a long-running history of complete hard freezes in MSHybrid mode. The internal screen can go black while the external display retains its last image, and the whole system stops responding, without a useful crash dump. dGPU-only mode was previously the stable workaround.

More recently, BSODs have also occurred in dGPU-only mode, including CRITICAL_PROCESS_DIED. The Samsung 980 has disappeared from BIOS after crashes. This makes storage connectivity, the M.2 slot/PCIe path, SSD controller, and broader platform power management relevant possibilities, but none is established as the cause. I am not assuming that the earlier hybrid freezes and the recent storage/BSOD symptoms share one root cause, or that this CPER alone identifies which event caused the record.

Current isolation test

The Samsung 980 has been moved into the other M.2 slot (the slot formerly occupied by the NX drive); the NX drive is removed, and the laptop is running in dGPU-only mode. This test is ongoing; no definitive result is claimed.

Samsung Magician reports the drive healthy, and Windows reports Healthy / OK. Those observations are included as context, rather than proof that an intermittent SSD/controller/slot fault is excluded.

Exact iclg v1.2.0 output

The following is a fresh read-only run against the retained 3408-byte CPER. The blank checksum column is reproduced as returned; I am not claiming a validated checksum.

iclg --version:

intel_crashlog_app 1.2.0

iclg info largest-whea.cper (warnings and table):

[2026-10-07T23:42:41Z WARN  intel_crashlog::cper::header] Unsupported CPER Record Header revision: 2.16.
[2026-10-07T23:42:41Z WARN  intel_crashlog::cper::descr] Unsupported CPER Section Descriptor revision: 3.0
[2026-10-07T23:42:41Z WARN  intel_crashlog::cper::descr] Unsupported CPER Section Descriptor revision: 3.0
  #   Record Type  Rev.  Product  Size  Skt  Checksum  Die  
----- ------------ ----- -------- ----- ---- --------- ---- 
 0-0  PMC              2 0x036     2560    0                
 1-0  PMC_TRACE        1 0x036      512    0                

iclg triage largest-whea.cper (captured combined console output):

[2026-10-07T23:42:41Z WARN  intel_crashlog::cper::header] Unsupported CPER Record Header revision: 2.16.
CRASHLOG_REASON.PMC.30010H
[2026-10-07T23:42:41Z WARN  intel_crashlog::cper::descr] Unsupported CPER Section Descriptor revision: 3.0
[2026-10-07T23:42:41Z WARN  intel_crashlog::cper::descr] Unsupported CPER Section Descriptor revision: 3.0
[2026-10-07T23:42:41Z WARN  intel_crashlog::record::decode] Cannot decode record: Missing decode definitions for PMC revision 2. Only the header fields will be decoded.
[2026-10-07T23:42:41Z WARN  intel_crashlog::record::decode] Cannot decode record: Missing decode definitions for PMC_TRACE revision 1. Only the header fields will be decoded.

The retained decoded JSON contains only pmc.hdr and pmc_trace.hdr. Relevant header values:

Field	PMC	PMC_TRACE
version._value	0x1036302	0x11036101
header_type	0x3	0x1
product_id	0x36	0x36
record_type	0x1	0x11
revision	0x2	0x1
record_size.record_size	0x280	0x80
record_size.extended_record_size	0x0	0x0
agent_version	0x130000	—
completion_status.completion_status	0x3ff	—
completion_status.record_collection_completed	0x1	—
reason	0x30010	—
timestamp	0x72e041b5	—

The JSON size values above are raw header fields; the byte lengths are the 2560 / 512 values reported by iclg info.

Related reports

• #99 reports missing collateral for product 0x037 (PMC rev 5 / PMC_TRACE rev 1 / PMC_RST rev 1) and the same triage string CRASHLOG_REASON.PMC.30010H. My product and PMC revision differ; I am not treating that as a transferable decode or proof of the same failure.
• #90 concerns product 0x00c (PMC rev 3 / PMC_TRACE rev 1). In the maintainer response, PMC definitions were added through #91, while internal referral of the PMC_TRACE binary was offered because public trace decoding could not be provided at that time.

Questions for Intel

1. What platform/PCH/agent does CrashLog product ID 0x036 map to? Please confirm independently of the CPU model, including what parts of the CPU/PCH/platform these records can and cannot describe.
2. Could you publish or provide the matching target_info.json and decode definitions, including the equivalents of decode-defs/PMC/2/layout.csv and decode-defs/PMC_TRACE/1/layout.csv, plus any reason/triage definitions needed for this product? If existing collateral applies, what exact package/version and invocation should be used?
3. What does PMC reason 0x30010 mean specifically for product 0x036 / PMC rev 2? Is it a collection trigger/reset category or evidence of a specific failure, and what conclusions would be unjustified from the reason alone?
4. Can the matching PMC/PMC_TRACE data distinguish PCIe/NVMe link or AER faults, platform reset causes, power-state/watchdog problems, or graphics-related platform hangs? What additional non-sensitive metadata would help you interpret these records?
5. Do the CPER header revision 2.16 / section descriptor revision 3.0 warnings affect confidence in parsing, or is a newer parser required?
6. If the definitions or trace decoder cannot be published, can Intel decode the retained records privately or forward them to the appropriate internal team, as offered in #90? Please provide an approved private submission channel and specify the minimum data required.

Data handling

The original CPER and decoded JSON are retained locally. No serial numbers, machine identifiers, raw firmware dumps, or binary crashlog/trace payloads are attached to this public issue. If binary records are needed for internal decoding, I would like to arrange a private transfer after Intel specifies the channel and required data.

Thank you.