Windows 7: Stop 0x124 Troubleshooting - 'New Method'

**Please read corrections (See link)**

Vir Gnarus - Post #4 - Corrections



I understand, that most of the current BSOD analysts on the forum, use and understand the more efficient way of analyzing Stop 0x124 crashes as pointed out by Vir Gnarus. Although, I would like to create page which enables new BSOD analysts to understand and use this method in their analysis.

Thanks for Vir Gnarus, for explaining this method, he has already created a brilliant tutorial on Sysnative about how to debug Stop 0x124 PCI errors (see External Links)

Here's the start of a 0x124 bugcheck (without any extensions used):

I've highlighted the areas which will interest us; so let's break the down the very beginning of the crash into simple parts.

The text in red, is basically the type of bugcheck, you can use this to find further information from the BSOD Index.

The text in blue, is the first parameter of the bugcheck, and this describes the cause of the error, which in this case is 0x4 and is linked to a Uncorrectable PCI Express Error.

0x4 can also mean a PCI error, as well as, PCI Express Error.

The text in green is the second parameter, and this describes the address of WHEA_ERROR_RECORD; we will use this address to extract some additional information.

As you can see we used the following extension with the address from the second parameter:

The Port Type shows where the error occurred, it seems to have happened within the PCI/PCI Express port, with the error severity being Fatal. We can also check the AER (PCI Express Advance Error Reporting) section to see what exactly happened.

I believe the capitalized parts are supposed to the most interesting and where the errors occurred, I think MTLP means Malformed TLP and ROF means Receiver Overflow.

In general, the parts indicate:

1. UR = Unsupported Request Error
2. MTLP = Malformed TLP
3. SD = Surprise Down
4. ROF = Receiver Overflow
5. UC = Unexcepted Completion
6. CT = Completion Timeout

What device is causing the crash? We can search the VenID or DevID using a PCI Database, and then check the Vendor ID or Device ID information provided by the database, with the information from the OP's msinfo32 file or their System Specifications which they may have uploaded.

However, the device may not always be the actual cause, it could be the port it is using or the motherboard. We can always use various stress tests and swaps in order to find a confirmation.

For processors, we can use the same extension (!errrec), however, less information will be displayed and I tend to just check the MCA (Processor Machine Check Architecture), here is an example:

EDIT:

I would like to thank Arc for pointing this out to me.

The first parameter or argument has the value of 0x0, which is a Machine Check Exception, which means the CPU has detected a hardware problem and the address points to a processor error because the CPU has found one, so it could be a different form of hardware which is causing the issue.

In such a situation, it is best to use these steps:

• Stop 0x124 - what it means and what to try

All the hardware seeming to be running stable and tests reporting no errors, could mean a bad motherboard.

External Links:

• WHEA - Windows Hardware Error Architecture
• STOP 0x00000124: WHEA_UNCORRECTABLE_ERROR
• PCI-E WHEA errors (0x124) - by Vir Gnarus

Thanks for the information Harry, & very nicely written thread.
I personally find the 124's very hard to troubleshoot.

Thanks Yussi, and 124's do take quite some time, especially when the stress tests do not indicate any errors.

Hi Bluerobot, thanks a lot for transferring this knowledge over to this forum for me. It definitely is good to get this around for others to know about as much as is available, and it certainly helps me having to personally direct people to where they can learn more about it every time I come across someone who isn't familiar.

I would like to benefit the article but adding a few clarifications, if I may:


The 0x4 subcode of the 0x124 bugcheck refers to the PCI-E bus, which is always true, as you pointed out. However, the PCI-E bus is a very commonly used bus for a whole assortment of things on the motherboard, and not just for PCI either. USB is also often shared on it, especially on OEM motherboards that like to keep things cheap by pushing a bunch of different items on the motherboard onto as few buses as possible. Don't rule out the possibility of it being something other than PCI-related! Check the motherboard brand and see if it's an OEM, and if it is, try correlating that crashdump with any other problematic behavior, like checking and seeing if the person is experiencing USB/Bluetooth issues and the like. Finding patterns in symptoms to correlate with this data goes a long way in establishing a more accurate conclusion!


As for PCI-E WHEA error records, yes, they are generated by the device that created the error, but the one that created the error isn't the one that caused the error! Much like any crashdump, the one who's found the problem and filing the report isn't the one who committed the crime. This also is the same with WHEA errors, especially PCI-E WHEA errors. Often you'll find that the device the reported the error is the root port, when all the root port is saying is, "I've found a problem and telling about it, but I really don't know where it originated from." The device id listed below it also correlates with the device telling the tale, so all it's telling you is the device id of the root port in this case, so it won't be of much assistance.


This particular crashdump you're using is very unusual. You see, the PCI-E WHEA error record will present 5 different items that are interest, which are the 3 Uncorrectable Error values and the 2 Correctable ones. It is important to understand what 'Status', 'Mask' and 'Severity' means to interpret these properly.

Status = Shows what issues have actually been discovered and are presented in the error report.

Mask = Shows what error types are masked and therefore to be disregarded, or to say, "Don't bother with this error if the system reports it, it's fine."

Severity = Shows which uncorrectable error types are considered a fatal error which cannot be recovered (therefore causing the BSOD).

Obviously, Correctable Errors do not harbor the Severity value because there shouldn't be any correctable errors that can be deemed fatal (why should they if they can be corrected?). So really the uncorrectable should be looked at, and it should be the Status of them in particular, when filtered through both Severity and Mask, since it's the Status that actually tells you what actually happened that caused the error. However, in this example, none of the values are highlighted (capitalized) so strangely no errors were collected on this WHEA error report! Talk about an oddity! Perhaps the error got lost during data collection. Very strange. I personally wouldn't know what to do with this, but having the PCI-E WHEA BSOD just means putting more attention on it and anything passing through it (be it PCI-E, PCI, USB, etc.).

Btw, the definitions for each of the error types is mentioned here. This only relates if the Root Port was the device the issued the error, which in this case it was. If something else, then locate the appropriate item at the bottom of the linked page. Also, despite me notifying them long ago, they haven't corrected the links for the Correctable Error Status and Mask pages under the Members section, but they are listed correctly at the bottom of the page. These 'definitions' are really only the names of each one. While names like 'Surprise Down' is somewhat self-explanatory, a Malformed TLP probably isn't so much. That information, however, is documented in the PCI Express Base Spec, which is not freely accessible (you may find an old copy lurking around on the internet, though).


Lastly, a description on how to understand generic WHEA errors (most common) besides the PCI-E specific ones I've mentioned here. Just to assure you, the developer manuals it refers too are free downloads, so don't worry bout that.

Thanks for the corrections Vir, I'll create a link for your post in the tutorial, or did you think it's best to quote it within the tutorial?

It's really up to you, skipper. It's your tutorial!

I've added a little link at the top of the page, thought the quote may be a little too large to add.