Here it is - it's the 02F2DCA crash.
I'm wondering that most of people here that are reporting this issue have high end PCs with 7700k, 8700k, etc. and 1080Tis or better.
Can this be somehow related to those high end CPUs or their architecture?
I can't believe we all have faulty CPUs out of a sudden?
EA Staff (Retired)Thanks @Benef1cient.
These crashes are a real mystery to me.
They are definitely real, since we have a bunch of consistent crash logs from numerous independent people.
The hardware registers in all these logs are in line with what you'd expect for the instruction that is reported as crashing.
The instruction that is crashing should NOT be able to crash in ANY way. The instruction is "test r15, r15". According to Intel's x64 instruction specs, that instruction shouldn't be able to crash since it doesn't have a "lock" prefix and it doesn't touch memory. (The lock prefix is for synchronizing threads and only allowed on certain instructions.)
So, something is broken. Maybe Windows' crash handler is misreporting the crashes? But then why do all the registers match what you'd expect for a crash at the indicated instruction, and why do the crash reports work flawlessly for every other crash?
So, the most likely explanation is still that the CPU is really crashing, that the OS is reporting the crash correctly, and that we have a malfunctioning CPU. But why? Intel is really good at making CPUs. I don't like assuming their CPUs are broken, because usually I'd be wrong. I much prefer believing that our source code has a bug, but I just can't find any way that I could cause these crashes if I wanted to, even writing malicious assembly code by hand. Which is why I went with assuming that it was an overclocking or overheating issue - that let the CPUs that Intel shipped still work properly out of the factory while explaining why they were malfunctioning in this code.
But then, @Benef1cient and @2Cavalier have both reported good experimental evidence that it isn't overclocking/overheating.
Which leaves us with a malfunctioning CPU as the best explanation. But again, Intel is really good at making CPUs, and I've never come across a hardware bug in their chips before, so I really don't like that explanation. But there's no valid explanation in the code either. And by "code" I mean the instructions that our game actually executes after it's compiled, not just the source code. I have found and worked around several compiler bugs in my career, so I know that the disassembly the CPU executes is authoritative, not the source code we write, even though they're supposed to be equivalent. But the instruction causing all the grief in this crash is "test r15, r15", which cannot cause a crash according to Intel's specs, even though it does.
I guess the "good" news is I could probably work around the most common EXCEPTION_BREAKPOINT version of this crash. When that happens, I could look at the instruction that caused this crash, and if it isn't a breakpoint instruction, I can tell the OS to go back and try to run that instruction again. This will just cause a delay of a few thousand cycles that you'd probably not even notice. I'd also need to keep track of when I do this using RDTSC so that I don't get into an infinite loop and cause the game to freeze instead of crash, if the CPU really does insist that the instruction is a breakpoint.
I have crash as well, I dont understand, I think this all happend after the Octane or one of the latest patches. I didnt ever get crash with a log before.
Before it would just close itself with no error to desktop, but since then I fixed that, but after some patch it now crashes with "technical error".
My temperatures are fine, CPU and GPU they are not in any critical states, they are at max 78c which is completely fine!
crash:
{
R5Apex: 00000000002F2DCA
EXCEPTION_BREAKPOINT: 80000003
}
cpu: "Intel(R) Core(TM) i7-7700K CPU @ 4.20GHz"
ram: 32 // GB
callstack:
{
KERNELBASE: 00000000000EBDD0
ntdll: 00000000000A3167
ntdll: 000000000008B5E6
ntdll: 000000000009F7DD
ntdll: 000000000000D856
ntdll: 000000000009E70E
R5Apex: 00000000002F2DCA
R5Apex: 00000000004C0B56
R5Apex: 00000000004C0F47
R5Apex: 00000000004BF767
R5Apex: 00000000004C1502
KERNEL32: 0000000000014034
ntdll: 0000000000073691
}
registers:
{
rax = 1
rbx = 0x000000533E356C80
rcx = 0
rdx = 2
rsp = 0x000000534816FA20
rbp = 450 // 0x000001C2
rsi = 0x000001E58C80BC20
rdi = 1913 // 0x00000779
r8 = 0
r9 = 24032 // 0x00005DE0
r10 = 447828 // 0x0006D554
r11 = 447828 // 0x0006D554
r12 = 448215 // 0x0006D6D7
r13 = 448215 // 0x0006D6D7
r14 = 1
r15 = 0x000001E3D32CF4F0
rip = 0x00007FF630CD2DCA
xmm0 = [ [2.1000008e+11, 0, 0, 0], [0x524393EC, 0x00000000, 0x00000000, 0x00000000] ]
xmm1 = [ [1e+12, 0, 0, 0], [0x5368D4A5, 0x00000000, 0x00000000, 0x00000000] ]
xmm2 = [ [5.7614989, 0, 0, 0], [0x40B85E33, 0x00000000, 0x00000000, 0x00000000] ]
xmm3 = [ [1.2099153e+12, 0, 0, 0], [0x538CDA49, 0x00000000, 0x00000000, 0x00000000] ]
xmm4 = [ [84808232, 0, 0, 0], [0x4CA1C245, 0x00000000, 0x00000000, 0x00000000] ]
xmm5 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm6 = [ [84808232, 0, 0, 0], [0x4CA1C245, 0x00000000, 0x00000000, 0x00000000] ]
xmm7 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm8 = [ [4284900, 7617600, 11902500, 23328900], [0x4A82C3C8, 0x4AE87880, 0x4B359E24, 0x4BB1FC42] ]
xmm9 = [ [1.9044e+08, 3.4028235e+38, 3.4028235e+38, 3.4028235e+38], [0x4D359E24, 0x7F7FFFFF, 0x7F7FFFFF, 0x7F7FFFFF] ]
xmm10 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm11 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm12 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm13 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm14 = [ [13.8, 0, 0, 0], [0x415CCCCD, 0x00000000, 0x00000000, 0x00000000] ]
xmm15 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
}
build_id: 1553899726
EA Staff (Retired)@2Cavalier, thank you for that generous offer in time, effort and hardware!
It would be an interesting data point if other identical CPUs had the same problem, especially at stock settings (just to rule out the overclocking factor in the experiment). If only one chip fails, that'd indicate it's probably something in that particular chip. If they all fail, that'd indicate it's likely related to the CPU microarchitecture, or that somehow your other hardware is involved (motherboard etc.). That information could be helpful, but it probably won't immediately point us to a solution.
Still, not knowing your plans for those CPUs, I would hate for you to lose any value on them by opening their boxes for this test.
Regarding something in your previous post, I doubt the GPU matters, but it is possible. There's always the outside chance of some electrical or thermal communication. Also, different GPU and frame capping configurations can alter CPU timing, which can affect the CPU behavior.
EA Staff (Retired)As more general info, the crash is happening inside a loop to decide what LOD to use for a bunch of models, and whether they should fade out. Looking at @Benef1cient's apex_crash.txt, I see that iteration 883 crashed processing model 96651. Looking at @TEZZ0FIN0's crash, I see that iteration 450 crashed processing model 24032. Looking at @Vaestroo's crash, he made it to iteration 3768 and model 408479.
There's no way through the loop that doesn't hit the instruction that crashes, so we've had hundreds or even thousands of iterations that didn't crash before we hit one that did.
Hey Guys.
Try to disable meltdown and Spectre fixes with Inspectre.... This fixed my crashes...
Hi,
I`ve searched though this thread but my crash code weren`t here. I will copy it down here. My CPU and GPu aren`t overclocked.
I`ve played for like a month, and crashes started appearing yesterday. 2 weeks ago i switched from Asus R9 380 to Zotac gtx 1070ti mini. 3-4 days ago I`ve updated my Bios.
Motherboard Msi x370 Gaming Plus
crash:
{
d3d11: 0000000000185C8E
EXCEPTION_ACCESS_VIOLATION(read): FFFFFFFFFFFFFFFF
}
cpu: "AMD Ryzen 7 1700X Eight-Core Processor "
ram: 32 // GB
callstack:
{
KERNELBASE: 00000000000EBDD0
ntdll: 00000000000A3167
ntdll: 000000000008B5E6
ntdll: 000000000009F7DD
ntdll: 000000000000D856
ntdll: 000000000009E70E
d3d11: 0000000000185C8E
R5Apex: 000000000046F135
R5Apex: 0000000000431A03
R5Apex: 00000000004B6D63
R5Apex: 00000000004B6E8C
R5Apex: 00000000004BEE80
R5Apex: 000000000044008F
R5Apex: 00000000004C84BD
KERNEL32: 0000000000014034
ntdll: 0000000000073691
}
registers:
{
rax = 0x000001E7C8BE5720
rbx = 0
rcx = 0
rdx = 0
rsp = 0x000000619AF38A40
rbp = 0
rsi = 0
rdi = 0x000001E6975332C0
r8 = 2
r9 = 0x000000619AF38BB0
r10 = 65535 // 0x0000FFFF
r11 = 1
r12 = 0x000001E6975332C0
r13 = 0x000001E7C8BE5878
r14 = 0
r15 = 2
rip = 0x00007FFA4D605C8E
xmm0 = [ [-nan, -nan, -nan, -nan], [-1, -1, -1, -1] ]
xmm1 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm2 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm3 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm4 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm5 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm6 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm7 = [ [0.077399381, 0, 0, 0], [0x3D9E8391, 0x00000000, 0x00000000, 0x00000000] ]
xmm8 = [ [0.055, 0, 0, 0], [0x3D6147AE, 0x00000000, 0x00000000, 0x00000000] ]
xmm9 = [ [0.94786733, 0, 0, 0], [0x3F72A76F, 0x00000000, 0x00000000, 0x00000000] ]
xmm10 = [ [0.2, 0, 0, 0], [0x3E4CCCCD, 0x00000000, 0x00000000, 0x00000000] ]
xmm11 = [ [0.040449999, 0, 0, 0], [0x3D25AEE6, 0x00000000, 0x00000000, 0x00000000] ]
xmm12 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm13 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm14 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm15 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
}
build_id: 1554860081
You keep assuming it's the CPUs that are broken yet they perform just fine in literally any other game, this is the only game I crash in. My CPU isn't even bring worked that hard when it's crashing and has been under much more stress without a single crash, it's just apex crashing people, that's not a coincidence
Community Manager
