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.
Whew.. ranted a bit there
