How can I speak with someone knowledgeable on complicated topics?

I am a moderator for Reddit's /r/TechSupport Discord server and have occasionally run into problems that seem to have zero documentation for whatsoever. I've put in support tickets to various manufacturers (Intel, MSI and AMI among others) and am extremely clear and detailed in my questions. In the first sentence I clarify that I am supporting someone else, this isn't my computer, and I am seeing this issue on multiple computers commonly enough that I want more information about the problem.

Invariably, and I mean every. Single. Time. The support agent replies with something completely dismissive, either saying I need to contact my system manufacturer, or they latch on to a small detail that implies it might not be their fault and paste something about contacting other support teams. I have yet to get a single intelligent response that actually answers the question, or even attempts to answer the question. I sent Intel and email regarding a weird BERT I had been seeing with a dozen links to forum threads and issues on Intel's own github where Intel employees even responded to those issues, and the first response I got back was "WHEA is a windows error reporting system, please reach out to Microsoft" despite multiple threads of the error happening on Linux. I then re-sent the links to the forum posts about the issue happening on Linux machines and got "If this is happening on Linux computers, please visit a Linux support community for assistance" and then I just gave up. Like, obviously they're not reading and they're just giving me some garbage to get the ticket answered for metrics.

How do actual professional technicians get information on complicated issues if no public documentation exists about them? I feel like there has to be some trick to this, or some support line that I just don't know about.  I'm a volunteer, but I would pay an extremely significant amount of money to ask someone with the actual information I'm interested in just so I could get solid, concrete information about things.

My most recent example, which has frustrated me far more than it should:

Hello,

 

I'm trying to track down some documentation for, or potentially the cause of a frequent WHEA report I've seen on several computers.

 

For information, I am a volunteer moderator for Reddit's Tech Support community and have developed a tool to gather system information such as hardware specs, drivers and their statuses, SMART health information, etc.. I've recently written a feature to collect and translate information from Windows' WHEA-Logger reports. We have people run this tool quite regularly when troubleshooting issues, and on a very significant portion of computers since adding this feature, I have been seeing a recurring log. 

 

It's primarily on MSI motherboards, and I initially reached out to them for information, but today I saw two on ASUS boards. One was a ASUSTeK ROG STRIX Z790-F GAMING WIFI running ASUS bios version 0703 with Base AMI 5001B. The second, which is where the log below stems from, is a ASUSTeK ROG STRIX B760-F GAMING WIFI running ASUS bios version 0406, with the same Base AMI 5001B.

 

 Anyways, the log is as follows:

 

"ErrorHeader": {
  "Signature": "52455043 -- VALID",
  "Revision": "101 -- INVALID",
  "SignatureEnd": "FFFFFFFF -- VALID",
  "SectionCount": "1",
  "Severity": "Information",
  "ValidBits": "0x00000001",
  "Length": "0x0000013C",
  "Timestamp": "2124-03-25T16:43:48",
  "PlatformId": "2939780d-a21e-2a59-75c0-c87f5408236b",
  "PartitionId": "00000000-0000-0000-0000-000000000000",
  "CreatorId": "2939780d-a21e-2a59-75c0-c87f5408236b - UNKNOWN GUID",
  "NotifyType": "BOOT_NOTIFY_TYPE_GUID",
  "RecordId": "0",
  "Flags": "0x00000000",
  "PersistenceInfo": "0x0000000000000000"
},
"ErrorDescriptors": [
  {
"SectionOffset": "0x000000C8",
"SectionLength": "0x00000074",
"Revision": "0x0100",
"ValidBits": "0x00",
"Flags": "0x00000001",
"SectionType": "93a41c2f-a09f-e7c2-ac1f-f2488f03eec3 - UNKNOWN GUID",
"FRUId": "00000000-0000-0000-0000-000000000000",
"SectionSeverity": "Information",
"FRUText": ""
  }
],
"ErrorPackets": [
   "e7 00 01 00 00 00 00 00 2f 1c a4 93 9f a0 c2 e7  - 0x00 - ç......./.¤.. Âç
ac 1f f2 48 8f 03 ee c3 74 00 00 00 56 00 65 00  - 0x10 - ¬.òH..îÃt...V.e.
6e 00 48 00 77 00 28 00 39 00 33 00 41 00 34 00  - 0x20 - n.H.w.(.9.3.A.4.
31 00 43 00 32 00 46 00 2d 00 41 00 30 00 39 00  - 0x30 - 1.C.2.F.-.A.0.9.
46 00 2d 00 45 00 37 00 43 00 32 00 2d 00 41 00  - 0x40 - F.-.E.7.C.2.-.A.
43 00 31 00 46 00 2d 00 46 00 32 00 34 00 38 00  - 0x50 - C.1.F.-.F.2.4.8.
38 00 46 00 30 00 33 00 45 00 45 00 43 00 33 00  - 0x60 - 8.F.0.3.E.E.C.3.
29 00 00 00"
]

 

Keep in mind, this error report is identical and has been seen on at least a dozen systems in the last week. Several things stand out to me. 

 

First, the revision is invalid. A WHEA report should use revision 0x0210, but this report is 0x0101. I don't understand this. I'm not sure if it's a windows bug or if the UEFI is using the incorrect revision for another reason.

 

Second, the Creator ID is unknown. Again, this doesn't make sense to me. The Creator IDs are predefined through CPER, and located in the Windows SDK header ntddk.h. I don't know where this ID comes from, how it's used inside a WHEA report in lieu of the predefined CPER IDs in ntddk.h, and google has no information about it whatsoever.  This creator ID differs between machines, leading me to believe it's an identifier for the UEFI version, but I have not paid that much attention to see if there's a pattern.

 

Third, the Section Type guid is the same guid spelled out in the error packet, which is `VenHw(93a41c2f-a09f-e7c2-ac1f-f2488f03eec3)` - This looks like a UEFI boot entry, but the only mention of this specific guid is from a single forum post on the MSI community forum from January. My tool only runs on Windows systems, so a UEFI boot entry booting into Windows should be the Windows boot manager, and if that's the case, I would expect a lot more information about this guid just from various random failures people experience and post about online. This guid does not change between machines and has been exactly the same on every computer in which this log occurs.

 

Somewhat surprisingly (to me, anyways) is that the data in the first 8 bytes before the section ID guid also changes across machines. This one is 0xe70001, whereas the packet on the Z790-F board starts with 0x070101. Without knowing the format of this error packet, I have no way of understanding the significance of this, but I imagine it's some sort of signature.

 

I understand this log is technically marked as "Information" however if something is being reported to WHEA as informational, people should be able to understand what information it's trying to report.

 

This is the motherboard and bios information from the most recent system with this log entry, but please keep in mind this log is on over a dozen computers. It is not unique to this computer.

 

Motherboard Product - ASUSTeK ROG STRIX B760-F GAMING WIFI
Motherboard Manufacturer - ASUSTeK COMPUTER INC.
BIOS Manufacturer - American Megatrends Inc.
Version - 0406
Release Date - 11/03/2022
Base - American Megatrends - 5001B

 

I'm hoping someone at AMI can point me in the right direction to identify the source and cause of this WHEA log, and ideally provide more information as to why it's using the incorrect revision and an invalid Creator ID guid.

No. That is what you will get out of them every time.

That is why we exist.

Know that ASUS BIOS should always be up to date as well most Asus boards have 3 to 4 ways of updating it including No Power on through dedicated USB in Rear I/O Panel. 

Read the Manuals, MSI has Videos.

So on the one you mention : ROG STRIX B760-F GAMING WIFI it should be running BIOS Ver : 1645    Released : 2024/03/22   As well the firmware needs updating. 

NOTE : All ASUS Products have a Support Page : most have updates for BIOS/Firmware/Drivers for Video Cards, Monitors, Routers ...always update ASUS.....

Note : your barking up the wrong tree as American Megtrends has nothing to do with anything after release.  You used to be able to buy your way in but is pointless.  (Considered it years ago)

All you need to do is update the BIOS and drivers from the M/B Support Page as per above and info below.

Know that ASUS Fast Boot should be turned off for the same reasons as below :

Turn off MS Fast Start : https://www.windowscentral.com/how-disable-windows-10-fast-startup /11 and WHY !!!

As most people do not know better and buy ram that is too fast for the chip and parts that have not been checked against M/B QVL page/s

Is pretty much the same for all MSI / Gigabyte / ASRock is a little more forgiving also less of them ever come here.    All modern Motherboards are meant  to be updated. (Period)

 

 

Note : your barking up the wrong tree as American Megtrends has nothing to do with anything after release

In many cases I agree with this. AMI makes the base bios, the board manufacturer adjusts it to be how they want it to be. A board being an AMI board is meaningless in virtually all scenarios. I get that.

In this case, this is an identical log across at least three different board manufacturers: ASUS, MSI and Dell. Somebody somewhere wrote the routine that reports this log to WHEA. WHEA itself doesn't detect errors, WHEA is simply an aggregate error reporting service that takes information from other sources and logs it. In this case, they're all BOOT_NOTIFY_TYPE_GUID, which is a boot error record. That should usually be a BERT, which stems from the UEFI, though admittedly this packet does not have the BERT signature. Regardless, it stems from the UEFI, and I can't imagine that three separate motherboard manufacturers all wrote a routine to file this exact same log to WHEA with the same GUID involved and the same strangeness with the WHEA revision number.

Given that it's from the UEFI, and the motherboard manufacturer isn't the ones that set up this log, the only common denominator is AMI.

You might be on to something with fast boot, though. I'll keep an eye out to see if there's any correlation there.

 

You might be on to something with fast boot, though. I'll keep an eye out to see if there's any correlation there.

Have been turning it off it seems like before the dawn of time.

It is very much a ASUS board thing to start but it is a all boards thing now & they benefit having it turned off as well as the MS Fast Start.

So that is the common outside of AMI

Note : some boards have multiple places in Bios that speed up the boot, others have their own software as well.    Is getting a little weird with that.

But regardless the 1st 2 are the common between them.

Will tag this to draw the @ubuysa BSOD Kernel Dump Expert to this for his thoughts on your topic :=}