BSOD Random, after Win7 boot. No programs running. Error Bugchk 0x124

Almagest · 22 Apr 2014

Hey this is my first post,

I've read most of the instructions on posting and hope I've done it right. This is the second computer I've built in about a week that is having this same BSOD. I am new to debugging so I'd like to know if I've come to the proper conclusion. I'm using WinDbg x64 to read the files. The last system I replaced the processor and it worked fine.

This computer reboots randomly, usually within the first 3 minutes of operation. No programs running.

I've included the information from using the DM LOG collector as instructed.

Thedoctor44 · 22 Apr 2014

It appears your CPU on this PC is causing issues.

Please follow these instructions and run Prime95 for around 2 hours.

Hardware - Stress Test With Prime95

If the PC blue screens when running Prime95 then please run it in Safe mode, if it still fails I'm afraid a new CPU will be the only option.

Code:

===============================================================================
Common Platform Error Record @ fffffa8007559028
-------------------------------------------------------------------------------
Record Id     : 01cf5e3ffe2361e4
Severity      : Fatal (1)
Length        : 928
Creator       : Microsoft
Notify Type   : Machine Check Exception
Timestamp     : 4/22/2014 15:35:32
Flags         : 0x00000000

===============================================================================
Section 0     : Processor Generic
-------------------------------------------------------------------------------
Descriptor    @ fffffa80075590a8
Section       @ fffffa8007559180
Offset        : 344
Length        : 192
Flags         : 0x00000001 Primary
Severity      : Fatal

Proc. Type    : x86/x64
Instr. Set    : x64
Error Type    : Cache error
Operation     : Generic
Flags         : 0x00
Level         : 0
CPU Version   : 0x00000000000306c3
Processor ID  : 0x0000000000000000

In this case a Machine Check Exception has been called and it has found a Cache error within the CPU.

A machine check exception is when the CPU finds a fault and reports it, generally the CPU gets the blame but in this case it looks like the CPU is actually at fault.

Nine times out of ten it appears 0x124 errors are caused by a faulty CPU, other pieces of hardware can cause it but it's not as common.

Almagest · 22 Apr 2014

Ok thank you very much. I'm really wanting to become a lot better at debugging myself. I am curious as to where you obtained the information in your response? Which program you use yourself or any place I can read up on tutorials. I will try the Prime95 tests now. Thank you once again

Thedoctor44 · 22 Apr 2014

Windows Debugger is one of the best ways to analyse a dump file.

If you are wanting to get better at debugging then I recommend starting by reading Windows Internals, I have asked many questions and learnt a lot from Vir Gnarus.

He once said to me this, I fully agree as well.

Did you know when you take a class in automobile repair that some of the stuff they start you off with is physics and chemistry? That's because they are the most basic things you need to understand to realize how a car actually operates. A car is the sum of all of its parts, so learning how those parts work by themselves is necessary to understand how it all comes together, and usually it comes down to the fundamentals, like physics and chemistry, and yes, even electronics.

An operating system is very much the same. The point is to get you - the user - to tell the hardware - the PC - to do something through software and have it do the job and get back with you on the results. There are many parts that work in tandem to make this happen, as each part of the OS works with different parts of hardware and software to make sure they all work decently and in order. Knowing how each part works and how they work together is crucial to deep troubleshooting like debugging, but it's also important to know the fundamentals under them, namely the programming languages (in Windows that's usually C/C++ and Assembly) and the hardware infrastructure the OS is working to keep under wraps.

So debugging and forensic troubleshooting are really a bunch of disciplines all wrapped up in a big package. You do not so much study and train to do debugging but rather train to learn each of these individual parts and how they work, and then you can apply that knowledge to troubleshooting when it doesn't work. It's like those who study forensics to find counterfeit money: they study every little detail of the real money so they can find what exactly is wrong with the fake ones. That's because there's many wrong ways to make counterfeit money, but there's only one way to make the real stuff, just like there's one way a computer should've done something but there's many ways it could mess up. You learn how cars run before you can learn how to repair them.

So the best way to get started in learning how to do debugging and crashdump analysis and all that good stuff is to get back to the basics. Learn the different programming languages (Assembly especially, since they all boil down to it in the end anyways), learn how the hardware works, and learn how the OS puts it all together. Occasionally take a break from learning them and see if what you learned can be applied to debugging and troubleshooting a problem.

Almagest · 22 Apr 2014

Thank you very much. I was looking into getting the Windows Internals to do just that. I am very knowledgeable in the automotive world. That analogy is probably the best one to use for me. I appreciate your time and insight once again. I've narrowed it down and the CPU is the culprit for sure. Thank you. Take care!