Are you overclocking? What are your current CPU BIOS settings? (GHz, voltage, etc.)
Yes. 5ghz on all cores with voltage set to 1.3v adaptive mode. Its stable on everything ive tested. After reading this thread, I decided to remove the overclock to see if the crashing stops. I havent played much yet to give a definite answer.
I have now played about ~16 hours and have yet to crash. Today I bumped my clock up to 4.8GHz from 4.4GHz and I think I’m staying there. Didn’t have a single issue at that clock for over 7 hours of playing. Highly recommend resetting to default bios settings or adjusting your overclock if you are still crashing a lot. The crashes described in this thread seem to be linked mainly to high overclocks.
Drop your overclock. Either get rid of it or decrease it. I have a 8700K and was running stable in everything up until the recent patches in Apex. Dropped mine from 5GHz down to 4.4GHz and didn’t crash at all over ~6-7 hours. Today I bumped it up to 4.8GHz and have yet to crash after another ~7-8 hours. I reset my entire bios back to default when I decreased it as well. I enabled XMP, disabled EIST and Turbo Boost, and put the clock at the specified speed that’s all I touched this time around and I have yet to have a crash since doing so. 5GHz seems to be common culprit but other with higher clocks have crashed to. Not sure what changed in the code that’s triggering the game to crash so much now at high overclocks.
Hello, thank you for taking time to help out on the forum.
Right before my game crashes I see a big spike in Commit charge (see image) I thought the crash had something to do with memory because of this or would this be an effect of the crash?
Also, do any of you feel that the crashes has gotten more and more frequent with the last two patches? would this be because lifted fps cap?
@FatSpacePanda, I don't know for sure, but I speculate that the spike is probably when the OS comes in and starts to handle the crash.
Based on all the logs and investigation we've done, I'm now convinced that this is a flaw with Intel chips. There is some sequence of instructions that causes results to be used before they're ready on Intel chips. There is one function in Apex that executes this sequence. It doesn't have to be a complex, CPU-intensive program to expose flaws like this; they could even show up in Notepad! I know that we have other functions that are heavily optimized that don't crash; this function that crashes so much is hardly optimized because it's so simple.
It seems that overclocking Intel chips can cause this to happen pretty reliably. It also seems that this can happen when Intel SpeedStep technology raises the clock speed without actually overclocking at all. In all cases, it seems that lowering your clock speed causes the crashes in this code to stop.
So, I base my conclusion that it is an Intel hardware flaw on the experimental evidence that the information about the CPU state that the OS reports for these crashes is always impossible for a properly functioning CPU, these crashes are only reported on Intel chips, and lowering the clock speed always fixes these crashes (even if it wasn't overclocked).
These crashes are exceedingly rare from a CPU perspective. If you crash every other game, that feels like a lot, because it is. My personal goal is nobody crashing ever! However, say that crashing every other game translates into crashing about once every 20 minutes. The CPU runs the instructions that crash at least 100,000 times a second when you're playing the game. With these conservative estimates, the CPU crashes about once every 120 million times it runs this code. So, even though it truly does crash a lot, the conservative estimate is that even a malfunctioning CPU actually functions properly in this code about 99.999999% of the time.
So, what next?
Well, I tried to isolate the crashing function to make a standalone program to exhibit the CPU bug. Unfortunately, I couldn't get the compiler to generate the exact same disassembly. Since the crash appears to depend on the actual sequence of instructions the CPU actually runs, if the disassembly is not equivalent, I don't think it's a good test. Even if I had identical instructions, I don't know that I could reproduce a data set that would cause this function to crash. The real data set depends on where you are in King's Canyon and which way you are looking. I can't replicate all the code and data to generate this data set in a standalone test program, so I'd have to generate random data and hope it crashes. But we've never seen this crash on any of our work machines, so I don't really have any way to verify that I've come up with a crashing data set.
All this to say, I've decided that it takes too much time to make a standalone program to try to repro this bug. The program has a low chance of succeeding, and I can't locally test whether it succeeds or not. Even if it we got lucky and it happened to work, then it would only help highly technical people hone-in their clock speeds, and it might help Intel fix their hardware flaw.
But, it wouldn't help everybody else who has an Intel chip who keeps crashing and doesn't post here and who doesn't want to mess with their clock speeds. I want to help them too! And as a consumer, I know that when you're crashing you don't really care whether it's the CPU's fault or the video card driver's fault or the game's fault; you just want the game to work.
So, I'm going to try changing the function that has all these impossible crashes to do the same job in a slightly different way, and hope that nudges it out of the "sweet spot" that causes some Intel chips to crash every few matches. Until we verify the fix, I'll leave in the old way as a hidden option, so we can be sure that we don't accidentally make things worse with no quick way to go back to the way things were. This is still a shot in the dark, because we can't repro the crashes on any of our machines, but it's the best shot I can take based on all the evidence in this thread.
Unfortunately, I don't know when these changes will go live through our regular release schedule.
Okay thank you. I first thought that the two were related since it was so much data (maybe the cpu got other instructions at the same time apex had something that otherwise would be a micro stutter ??) I don´t know, im way out of my depth.
April 2019 - last edited April 2019
@OrioStorm Thanks for detailed summary!
It also may be worth noting that you have increase the CPU voltage (vCore) to avoid the following non-crash error:
Event ID 19
A corrected hardware error has occurred.
Reported by component: Processor Core
Error Source: Corrected Machine Check
Error Type: Internal parity error
Processor APIC ID: 0
For me, a stable vCore was 1.28v for the I9-9900K, with vDroop on my motherboard this gave me a 1.25v-1.26v consistent vCore while gaming. If it drops to 1.21v-1.23v, I get the CPU parity errors above while I play.