ralish / DecodeWheaRecord

Decode hex-encoded Windows Hardware Event Architecture (WHEA) records
MIT License
13 stars 1 forks source link

Unable to decode WHEA Boot Error Record #5

Closed kowjacalski closed 3 months ago

kowjacalski commented 3 months ago

Hello,

d:\UTILS\DecodeWheaRecord>DecodeWheaRecord.exe 435045520101FFFFFFFF010003000000010000003C0100002B2A08001E0518159C6B0037C03500000000000000000000000000000000000000000000000000009C6B0037C0350000000000000000000066A4613D40AB9A40A698F362D464B38F0000000000000000000000000000000000000000000000000000000000000000C80000007400000000010000010000002F1CA4939FA0C2E7AC1FF2488F03EEC30000000000000000000000000000000003000000000000000000000000000000000000000000000007010100000000002F1CA4939FA0C2E7AC1FF2488F03EEC374000000560065006E00480077002800390033004100340031004300320046002D0041003000390046002D0045003700430032002D0041004300310046002D0046003200340038003800460030003300450045004300330029000000

[WHEA_ERROR_RECORD_HEADER] Expected major revision 2 but MajorRevision member is: 1

Microsoft-Windows-Kernel-WHEA/Errors from Windows 10 are not supported?

Could you please help decode this WHEA error?

ralish commented 3 months ago

@kowjacalski What version of Windows is this from?

ralish commented 3 months ago

@kowjacalski Nevermind, can decode part of the record. Will provide an update tomorrow.

ralish commented 3 months ago

So there's two issues here. The first is that the utility is exiting on decoding the error record if the revision doesn't match the latest version (v2.16). That's clearly wrong, and I've pushed an update which now only warns if a newer revision than what's expected is encountered, but continues to attempt to decode the record. That results in the following given your error record:

[WHEA_ERROR_RECORD_HEADER] Expected size: 128 | Current offset: 0
[WHEA_ERROR_RECORD_SECTION_DESCRIPTOR] Expected size: 72 | Current offset: 128
[WHEA_ERROR_RECORD] Header indicates error record contains 316 bytes but marshalled 200 bytes.
{
  "Header": {
    "Signature": "CPER",
    "Revision": {
      "MinorRevision": 1,
      "MajorRevision": 1
    },
    "SignatureEnd": 4294967295,
    "SectionCount": 1,
    "Severity": "Informational",
    "ValidBits": "PlatformId",
    "Length": 316,
    "PlatformId": "37006b9c-35c0-0000-0000-000000000000",
    "CreatorId": "37006b9c-35c0-0000-0000-000000000000",
    "NotifyType": "Boot Error Record (BOOT)",
    "RecordId": 0,
    "Flags": "",
    "Reserved": "AAAAAAAAAAA="
  },
  "SectionDescriptor": [
    {
      "SectionOffset": 200,
      "SectionLength": 116,
      "Revision": {
        "MinorRevision": 0,
        "MajorRevision": 1
      },
      "ValidBits": "",
      "Reserved": 0,
      "Flags": "Primary",
      "SectionType": "93a41c2f-a09f-e7c2-ac1f-f2488f03eec3",
      "SectionSeverity": "Informational"
    }
  ],
  "Section": []
}

So we can see a Boot Error Record (BOOT) has been logged at Informational severity. Unfortunately, the error record section isn't decoded (the remaining 116 bytes) as we don't know the structure for this type of section (given by the GUID: 93a41c2f-a09f-e7c2-ac1f-f2488f03eec3).

WHEA records are binary and each section has its own unique format, and many of these aren't documented. I couldn't find any information on this specific GUID, so it's probably defined by the manufacturer and non-public (e.g. by Intel).

A hex-dump of those 116 bytes gives:

          Offset Bytes                                           Ascii
                 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
          ------ ----------------------------------------------- -----
0000000000000000 07 01 01 00 00 00 00 00 2F 1C A4 93 9F A0 C2 E7 ���     /�¤�� Âç
0000000000000010 AC 1F F2 48 8F 03 EE C3 74 00 00 00 56 00 65 00 ¬�òH��îÃt   V e
0000000000000020 6E 00 48 00 77 00 28 00 39 00 33 00 41 00 34 00 n H w ( 9 3 A 4
0000000000000030 31 00 43 00 32 00 46 00 2D 00 41 00 30 00 39 00 1 C 2 F - A 0 9
0000000000000040 46 00 2D 00 45 00 37 00 43 00 32 00 2D 00 41 00 F - E 7 C 2 - A
0000000000000050 43 00 31 00 46 00 2D 00 46 00 32 00 34 00 38 00 C 1 F - F 2 4 8
0000000000000060 38 00 46 00 30 00 33 00 45 00 45 00 43 00 33 00 8 F 0 3 E E C 3
0000000000000070 29 00 00 00                                     )

So we can see most of the record actually is just the string VenHw(93A41C2F-A09F-E7C2-AC1F-F2488F03EEC3), matching the GUID we saw earlier in the section descriptor, but what the rest of the bytes mean I can't say.

Given this is an informational severity record, it's probably just diagnostic information being logged by the firmware and not anything to be concerned about.

ralish commented 3 months ago

@kowjacalski I analyzed the record you provided as best I can in the previous comment but accidentally posted a partial analysis, so any email you got is likely incomplete. See the full comment on GitHub for all the details.