I've seen those lists before. I can't personally find any way to pinpoint specific bugchecks to OC issues, and I also can't see how these people can find any correlation at all. I wonder if there's actual extensive research through pattern discovery here, or if it's just something based on conjecture.
I've been aware of this list and similar related comments, mostly on overclocking forums, for some time; my guess is that most were based on personal experiences during the trial and error stages of pushing their own rigs to find the stable limits.
Perhaps E-Peen could shed some light on this from his OCN connection (OCN is mentioned at the foot of the OP).
Leading off of Vir Gnarus' post, this list really grinds my gears, and I'll explain why. Mostly, this list is plastered around too much as a "general BSOD list", which leads people to believe that is the cause of their BSODs. At the end of the day, all we want to do is solve a BSOD and make the end user happy. As we know, our community of knowledgeable analyzers and debuggers is fairly small, so it's always nice to get a second set of eyes. However, this list is usually used incorrectly and that's why it bothers me. These days, especially on the Ivy and Sandy Bridge chipsets mixed with the new UEFI BIOS, overclocking isn't as difficult as it used to be... but it still isn't raise this, raise that, boom.. stable. You have to test, have patience, etc. I've heard and read before that 0x124 in the OVERCLOCKING sense does apply to vCore in most cases, but normally to us it just means possible hardware failure, let's go ahead and run an !errrec on the 2nd argument address
With this being said, I just think a list like this is way too impractical, but again... maybe that's just the analyst in me ranting and being biased. There are so many different variables in a BSOD, even in an overclocking situation. For example, in that list, 0x0A is listed, which we know is the IRQL NOT LESS OR EQUAL bugcheck. I think even in a situation of overclocking, pinpointing it solely on "unstable RAM/IMC, increase QPI first, if that doesn't work increase vcore" is a bit silly, and as satrow said... I feel this list was made based off of personal experiences whilst overclocking.
Like I said, it's a neat list, but I find it difficult to appreciate in most cases. For me personally, if a user has a component OC'd, I really don't proceed in the troubleshooting until it has been reverted to stock and it has been ensured that the specific OC'd component that is now stock, is not the issue. Bringing an OC back to stock literally chops HALF of the stress and work in half that we analysts have to worry about.
I agree with Satrow here - this list appears to be the result of trial and error work on overclocked systems.
But it does 2 things:
1) it increases our awareness of hardware issues and how those issues may apply to BSOD's and overclocking.
2) it gives us another alternative "fix" in case our usual procedures don't work. Attempting these fixes may be especially appropriate with the Asus M4 and P5 series of motherboards (which have a known history of memory issues in the BIOS).
I can admit that there is some truth behind the list. For example, given 0x0A bugchecks as E-Peen mentioned, the most common causes of this bugcheck is either a bad memory pointer, or a good pointer pointing to bad memory. While CPU problems can corrupt the pointer, often times it's the RAM corrupting it, and in the latter case with it pointing to bad memory it's always the RAM, as the page(s) in memory it was pointing too got lost. The result is that the system thinks it was paged out or deleted by common memory-saving cleanup work, and it was therefore going to go into the paging file to recover it, which is a no-no in higher IRQL states.
So yes, it as well as others listed do fit the bill with RAM being most evident cause, and there are some that are more directed towards CPU or even GPU issues. However, that's really as generic as you can get. I don't understand how they could get beefing vcore or QPI would help for specific scenarios. Though really, if you check the list carefully, you'll notice the guy is pretty unsure about each entry anyways, and ends up giving you several solutions for a suspected problem. The guy is probably as much in the dark about them as we are, though it does help an OCer much when they are testing on an otherwise stable PC and adjusting a specific setting appears to be causing such-n-such bugchecks. It's just not going to be very consistent.
Hi guys, I am an overclocker. All good OC forums will stress making sure the system is stable at stock settings before attempting any OCing. This verifies hardware is sound and good. Then one starts with either CPU or RAM with the GPU last. When one is stable the next is started and made stable and so on. The error codes in my case have been accurate, so far at least. I know we are often thought of as the "wild bunch" or demented, I plead guilty on both counts but it is fun.
It may be prudent to try the list next time one of you has an OP who is overclocking and see what happens. Often errors in memtest86+ can be corrected by either a DRAM volt adjustment on memory controller volts. I experienced this, I had over 3000 RAM errors in less that 10 secinds which was the voltage at fault. I'm using that RAM now.
Those bug checks were arrived at largely by 1000's of people doing tests on their own systems and without a degree of any kind. We OCers have many, many BSODs and usually find the fault.