Apex Legends Crash no error - PC (apex_crash.txt)

@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?

crash:
{
nvwgf2umx: 0000000000B16F81
EXCEPTION_ACCESS_VIOLATION(write): 00007FF8D03B6EC8
}
cpu: "Intel(R) Core(TM) i5-7500 CPU @ 3.40GHz"
ram: 16 // GB
callstack:
{
KERNELBASE: 00000000000FFB5A
ntdll: 00000000000A4AB2
ntdll: 000000000008C676
ntdll: 00000000000A119F
ntdll: 000000000006A229
ntdll: 000000000009FE0E
nvwgf2umx: 0000000000B16F81
nvwgf2umx: 0000000000DBC8D6
nvwgf2umx: 00000000003A9634
nvwgf2umx: 000000000039A200
nvwgf2umx: 00000000003A2AFD
nvwgf2umx: 00000000003A29A9
nvwgf2umx: 0000000000399CED
nvwgf2umx: 0000000000BFA46A
nvwgf2umx: 00000000012A552C
KERNEL32: 0000000000017BD4
ntdll: 000000000006CE71
}
registers:
{
rax = 0x0000023959CCC260
rbx = 0x0000023A6446DA10
rcx = 0x00007FF8D03B6BF0
rdx = 0x0000023959CCBFC0
rsp = 0x0000009CC70BF5A0
rbp = 0
rsi = 0
rdi = 0x00000238CD910990
r8 = 11
r9 = 0x00000238A373F5E0
r10 = 0
r11 = 0
r12 = 0xFFFFFFFE
r13 = 0
r14 = 1
r15 = 0
rip = 0x00007FF898606F81
xmm0 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm1 = [ [6.4571833e-42, 0, 1.4012985e-45, 1.4012985e-45], [4608, 0, 1, 1] ]
xmm2 = [ [0.0015138, 0, 0, 0], [0x3AC66AB3, 0x00000000, 0x00000000, 0x00000000] ]
xmm3 = [ [136, 0, 0, 0], [0x43080000, 0x00000000, 0x00000000, 0x00000000] ]
xmm4 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm5 = [ [16, 0, 0, 0], [0x41800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm6 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm7 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm8 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm9 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm10 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm11 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
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: 1562876448