Random, frequent panic reports

iMac 27 "- Retina 5K, 27-inch, 2017, 3,5 GHz Intel Core i5. 8G RAM. Setup as brand new, out-of-the-box.

I am trying to obtain help for I am yet to take it to a store and would like to be able to assess how they intend to repair it.

I would appreciate if anyone has had the same experience, and would be willing to share the solution, of random and frequent Panic Reports that don't have much data to help - unlike dtrace panics, they do not indicate they were caused by sw.

The problem with trying to troubleshoot in safe mode is that it is a somewhat limited env., and this crash can happen randomly, after two days or two months.

I suspect even having only original RAM, but only 8 G as sold, might be the culprit. I ran all sorts of tests: benchmarks (cinebench, heaven, prime95 etc.), memtester, crashme, memory_pressure etc. The iMac hangs in there... and then somewhat later (but never immediately), for no particular reason: crash! It could be when opening an XLS file or watching something on YouTube.

Always the same result: the screen goes "blank" of sorts.

I have been using iMacs with great pleasure since mid. 2015, not a single crash let alone panics.

This system was bought brand new at an Apple store, and on the second day of use, out of the blue, it:

• crashed;

• split the display in two-colored rectangles -- but as of lately it was all red;

• generated a Panic Report that doesn't have much data to help:

"* MCA Error Report * CPU Machine Check Architecture Error Dump (CPU: Intel(R) Core(TM) i5-7600 CPU @ 3.50GHz, CPUID: 0x906E9) - CATERR detected! No MCA data found."

Sadly to say this has been happening ever since:

Unfortunately, OS updates didn't fix this what seems to be a hw. issue, for Intel's Developer Manual says:

"15.1 MACHINE-CHECK ARCHITECTURE The Pentium 4, Intel Xeon, Intel Atom, and P6 family processors implement a machine-check architecture that provides a mechanism for detecting and reporting hardware (machine) errors, such as: system bus errors, ECC errors, parity errors, cache errors, and TLB errors. It consists of a set of model-specific registers (MSRs) that are used to set up machine checking and additional banks of MSRs used for recording errors that are detected.The processor signals the detection of an uncorrected machine-check error by generating a machine-check exception(#MC), which is an abort class exception. The implementation of the machine-check architecture does not ordinarily permit the processor to be restarted reliably after generating a machine-check exception. However, the machine-check-exception handler can collect information about the machine-check error from the machine-checkMSRs. Starting with 45 nm Intel 64 processor on which CPUID reports DisplayFamily_DisplayModel as 06H_1AH (seeCPUID instruction in Chapter 3, “Instruction Set Reference, A-L” in the Intel® 64 and IA-32 Architectures SoftwareDeveloper’s Manual, Volume 2A), the processor can report information on corrected machine-check errors anddeliver a programmable interrupt for software to respond to MC errors, referred to as corrected machine-check error interrupt (CMCI). See Section 15.5 for detail.Intel 64 processors supporting machine-check architecture and CMCI may also support an additional enhancement, namely, support for software recovery from certain uncorrected recoverable machine check errors. See Section 15.6 for detail.

15.9 INTERPRETING THE MCA ERROR CODES When the processor detects a machine-check error condition, it writes a 16-bit error code to the MCA error code field of one of the IA32_MCi_STATUS registers and sets the VAL (valid) flag in that register. The processor may also write a 16-bit model-specific error code in the IA32_MCi_STATUS register depending on the implementation of the machine-check architecture of the processor. The MCA error codes are architecturally defined for Intel 64 and IA-32 processors. To determine the cause of a machine-check exception, the machine-check exception handler must read the VAL flag for eachIA32_MCi_STATUS register. If the flag is set, the machine check-exception handler must then read the MCA error code field of the register. It is the encoding of the MCA error code field [15:0] that determines the type of error being reported and not the register bank reporting it. There are two types of MCA error codes: simple error codes and compound error codes."

I am yet to take it to a repair test for I have, as you all probably do, the engineer mentality, trying to understand the root cause for a brand new system behaving this way. It seems imho hard to fathom that a brand new system has to have the OS reinstalled from scratch, as often suggested by Apple's support.

Solution 1:

There is certainly something wrong with your hardware (graphics card). It surely is damaged and needs replacement. Call the Apple Help Center.

To further verify it, you can try to load something challenging for the graphics card.