Forum Discussion
@Benef1cient - Thanks for your feedback. I went back through this whole thread and didn't see any apex_crash.txt from you, so I don't know whether you're getting one of the crashes I've already commented on. But I can tell from our source code history that this one function that is reporting these crashes has not changed since before Apex Legends first shipped. If you'd be willing to post an apex_crash.txt, I can tell whether you are getting this or another crash.
@Falkentyne - Thanks for those suggestions. I looked into them. Unfortunately, you cannot write code to generate a "CPU Parity Error", because this is an error reported by the CPU itself to indicate that it is malfunctioning. Similarly, WHEA is Windows Hardware Error Architecture - it exists to report hardware errors (your machine itself), not software errors (the programs you run on the machine). The best we can do is try to get the compiler to generate a different set of instructions that achieves the same computation while luckily managing to avoid the hardware errors. This is very hard to do when we can't repro the errors internally. It would be like the movie where a blind guy keeps turning one face of a Rubik's cube and then asking his friend, "is this it?"
Regarding your AVX suggestion, Apex doesn't use AVX on PC, since our min-spec CPU doesn't include AVX. However, AVX and SSE often use the same hardware. It actually looks like AVX was designed so you could implement it in a CPU by reusing SSE execution units and registers, and just changing the instruction decode part of the chip! (You can treat one AVX register as two SSE registers put together, and an AVX instruction as running the equivalent SSE instruction sequentially on both SSE register pieces.) CPU hardware is allowed to have completely separate execution units for SSE and AVX, but given how CPU designs always want to minimize chip size and power usage, I would expect AVX and SSE to share execution units on all existing CPUs.
@2Cavalier - Thanks for your feedback. Your crash is the less common one that looks like stack corruption. I'm still trying to see how this might be possible based on source code and disassembly.
@JorPorCorTTV - Thanks for those logs. Three out of 4 of your crashes are the "02F2DCA" crash, where the CPU is saying that the instruction "test r15, r15" is really the instruction "int 3". apexcrash_2.txt is the less common "02F2E2A" crash, which looks like stack corruption. It's helpful to have as many of these dumps as possible as I try to look for clues.
@novemb9r - Thanks for the two logs. Your first log is the less common version of the "02F2DCA" crash, where the CPU is saying that the instruction "test r15, r15" tried to write to memory address "1". But this instruction does not write to any address! If you look at the Intel specifications of the "test" instruction's behavior, the only exceptions it is allowed to throw on the CPU are related to memory read accesses or to incorrectly using a "lock" prefix. We don't have a "lock" prefix, and the instruction is the register/register form so it doesn't read memory. This means this instruction should never be able to throw any exceptions according to Intel's specifications. Furthermore, this instruction does not write to memory according to Intel's specifications. So the most logical explanation is a malfunctioning CPU.
Your second log is the more common "02F2DCA" crash, where "test r15, r15" is treated as "int 3".
@MagiTwit - Thanks for the log. Your crash is actually different than all the others! Based on a google search, I'm guessing that "IGO64.dll" is Origin's in-game overlay. It looks like it tried to call a function that didn't exist any more. Based on the address it tried to call, it looks like this is probably because the DLL that had that function got unloaded, so it may not even be the in-game overlay's fault (i.e., it may be that the DLL got unloaded when it shouldn't have). I'm going to see if we can forward this to EA's Origin team. Do you happen to remember what you were doing at the time of this crash?
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?
- OrioStorm7 years ago
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.
- 7 years ago@OrioStorm If it would be helpful, I have 3 more 8700ks. Two are new and still in box, one in another machine. I could start swapping them into my gaming box and continue to test.
I understand how difficult this stuff can be to debug and appreciate the communication and transparency. Let me know if I can assist in anyway.- 7 years ago
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
- 6 years ago
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
- 7 years ago
I have an AMD Ryzen 5 1600x, 16 GB memory, Geforce 1070ti. I am not OC the build at all. I do have W10 -
1903 update sitting there to be installed. going to give that a try
About Apex Legends Technical Issues
Community Highlights
- EA_Blueberry7 years ago
Community Manager
Recent Discussions
- 2 hours ago
Nintendo switch linking
Solved4 hours ago- 4 hours ago