flynn017

I've listed other WHEA data structures in my other blog posts, and therefore will not be listing the same ones here. The purpose of this blog post is to list the WHEA data structures available with WinDbg, and Microsoft's Public Symbol Server. The information within the structures has more or less been explained in my other WHEA posts, but if in doubt please leave a comment or read the WDK documentation. _WHEA_ERROR_STATUS _WHEA_ERROR_RECORD_HEADER_FLAGS _WHEA_ERROR_PACKET_V2 _WHEA_ERROR_PACKET_FLAGS _WHEA_ERROR_TYPE _WHEA_ERROR_SEVERITY _WHEA_ERROR_SOURCE_TYPE _WHEA_ERROR_PACKET_DATA_FORMAT _WHEA_ERROR_RECORD _WHEA_ERROR_RECORD_HEADER _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR _WHEA_REVISION _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR_VALIDBITS _WHEA_ERROR_RECORD_SECTION_DESCRIPTOR_FLAGS

A new month, a new post and a old topic. It's back to the Stop 0x124 once again, and this time I'm going to explain the !whea extension, which outputs the high level structure of the WHEA architecture. You'll need at least a Kernel Memory dump to use this extension. Take into account the current error record address for the WHEA_ERROR_RECORD structure, and the error source notified. We can actucally view the data structure with the dt nt!_(name) command, I've added the -r switch to dump all the substructures too; here is a partial output: Here is the !whea output. I've highlighted the address of the current WHEA_ERROR_RECORD present in our dump file, as the main error record for the crash. I've highlighted the source of the error, and the type of hardware platform which the error record falls under. We can see that one error has caused a bugcheck, and the rest are corrected errors. The rest of the !whea output is below: Let's explain what each of these fi...

After this blog post, I think I've covered all the aspects of a Stop 0x124. Otherwise, you may see a few more posts about it in the future. I'm also planning on adding a few more debugging extensions, and will provide a updated version of a Stop 0x101. WHEA General Structure and Reporting: WHEA has the following general component structure:   LLHEHs are used to perform hardware error source discovery, gather information about the error source in the form of Hardware Error Packets, and then notify the operating system of the error. The Windows Kernel then formats these Hardware Error Packets into Error Records. Here is the general format of a Error Record for WHEA:  Each Error Record is described by the WHEA_ERROR_RECORD structure which provides information about the error condition. This is then saved in the Event Log through ETW (Event Tracing for Windows). When a error condition has happened, the LLHEH may communicate with the PSHED to receive platform specific information ...

Another blog post about Stop 0x124, as always said, these bugchecks are probably one of the hardest to debug due to the lack of information they retain, thereby it's very important to understand how to gather as much as possible from these seemingly barren dump files. I'm going to explain the rest of the !sysinfo extensions, !cpuinfo , !whea and !errpkt . In regards to !sysinfo , I'm going to discuss the flags to the extension highlighted with the red box. Let's begin with the !cpuinfo extension, which will show some basic information about the CPU. By default, it will display information about all the processors in the system, however, since this is a Mindump so one processor; the processor which was last running will be shown. The MHz field shows the clockspeed of the processor. The Manufacturer field is used to show that the processor is a real Intel processor. The CP field shows the current processor number. The F indicates the processor family number; the M indic...

Poisoned TLP ( PTLP ) -A TLP packet is usually considered as "poisoned" when it contains bad data, the receiver knows that a TLP is poisoned as a result of this. Only data which corresponds to read or write requests (posted or non-posted) is applicable to be considered as a TLP which has been poisoned. A PTLP is marked in the Header of the TLP with the EP bit being set. Any other forms of bad data are considered as Unsupported Requests (Memory, I/O or Messages). See Section 2.7.2.2. Flow Control Protocol ( FCP ) - This quite a simple error, in that it suggests that a Flow Control Protocol rule has been broken. Flow Control Information is carried as FCPs (Flow Control Packets) which is a type of DLLP as a explained in Part 2. See Section 2.6.1 for a entire listing of rules. Again, I'll add a few for your convenience. Each Virtual Channel (Data Buffer) uses a separate credit control flow system, and therefore is independent of other channels. Any TLP receivers which are re...

Continuing from Part 1, this second part is going to elaborate on the errors which were described in my previous blog post. Here, I would strongly recommend you download the PCIe 1.1 Specification, which isn't freely available to download from the PCIe website, but you can find a copy on Google. The error table is available in section 6.2.7 of the PCIe 1.1 Specification. In general, here is what the PCIe AER Extended Capability Structure looks like: Let's begin with the Unsupported Request Error ( UR ).  Unsupported Requests are basically requests which are not supported, they can be a result of several things. One being the device power states , any I/O TLP or Memory related TLP request being sent when the power state is D1, D2 or D3 is treated as a unsupported request (see section 5.3.1). I'll explain TLP's later. There are several errors which can cause a Unsupported Request error, from the PCIe 1.1 Specification, here is a listing with the references to the appropri...

I've bumped into a Stop 0x124 bugcheck, which was sourced from a PCI or PCIe bus on the motherboard. It's been a very long time since I've debugged one of these bugchecks (PCIe that is, not CPU), and in fact I did write a tutorial of how to debug these types of crashes, but that tutorial is quite dated now and I've quite a few more things since it's writing, therefore I'm going to create an updated version here which will bring everything together. I already know this tutorial is going to have be split across mulitple posts, since there is so much information about PCIe errors that I need to explain. Fortunately, there is some free specification documents availalbe online, so I would download those right away. I'm hopefully going to explain all the fields within the AER (more on that later) and the errors which caused the bugcheck. Okay, that was a lengthy introduction already, but in this first part, I'm just going to show you the general structure of t...

We all know that Stop 0x124 contain very little practical information to work with, the stack consists of WHEA reporting routines and many commands have no significance to a Stop 0x124. The first thing to look at with a Stop 0x124 is the clock speed of the processor, generally a overclocked processor will mean that the user has most likely overclocked their GPU or RAM, and also changed the voltage settings. However, the !sysinfo cpuspeed extension does not always work like below: This is quite annoying, but there are other ways to view the clockspeed of a processor, we can see the !prcb extension to view the Processor Control Block, which is a private kernel data structure used to store thread scheduling information; DPC queue, detailed CPU vendor information and cache sizes etc. Using the !prcb extension doesn't provide much information, but using the address fffff780ffff0000 with the _KPRCB data structure will provide some very detailed information. Please be aware that not sp...

Okay, we all know that Stop 0x124's are very generic and irritating bugchecks since they don't provide much information at all to be honest. Although, this can be made easier by following reading the error mnemonics within the CPU documentation, which will provide further insight into how the error was caused. I actually learned this in I think it may have been one of Vir's quotes in one of YoYo's posts, so thanks for providing information on where to find the documentation. You will want to download the .PDF file of Intel 64 and IA-32 Architectures Software Developer's Manual Volume 3: System Programming Guide , and then turn to page 2352. Here you will find the error mnemonics for the type of error, remember we can find the type of error and then decrypt it's meaning by using the !errrec extension with the second parameter of the bugcheck. Due to size limitations in which the Snipping Tool can expand to, I've taken a screenshot of  the relevant part of t...