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

[Lunchb0x88]

@OrioStorm I have a huge folder of Apex crash files as I continue to crash all of the time. Its the only game that crashes on my computer. Here is a selection of them: 

PC Specs:

9900K

2080ti

32GB DDR4 3200mhz

Windows 10 Pro

Installed on Samsung 970 EVO nvme SSD

[Lunchb0x88]

@OrioStorm Continued

[Lunchb0x88]

@OrioStorm If you need more, I can post more. 

[TEZZ0FIN0]

I just wanna say that I didnt get a single crash after changing back to default and just tweaking a few settings.

For the most part I was playing with V-sync off for no input lag or I was trying with adaptive 1/2.

With V-sync off and adaptive 1/2 the game was crashing very frequently.

I always thought crashing was very weird because the friends im playing with never had crashes but I did, so whats the deal..

They would ask me like "seriously, now again??", so I went back to default which they are using too, and now its not crashing frequently anymore.

I would play with low settings and v-sync off for high FPS and minimal input lag.

I went back to default and havent touched much with lightning or LOD in settings. 

Now I can play for hours with no problem, as otherwise it would crash in almost every match..

if this is a "temporary fix" I think its a big breakthrough!

edit: I think the key here might actually be Triple Buffered for some reason..

My friends with default settings are also ofc all using this too..

[TEZZ0FIN0]

I just wanna say that I didnt get a single crash after changing back to default and just tweaking a few settings.

For the most part I was playing with V-sync off for no input lag or I was trying with adaptive 1/2.

With V-sync off and adaptive 1/2 the game was crashing very frequently.

I always thought crashing was very weird because the friends im playing with never had crashes but I did, so whats the deal..

They would ask me like "seriously, now again??", so I went back to default which they are using too, and now its not crashing frequently anymore.

I would play with low settings and v-sync off for high FPS and minimal input lag. I went back to default and havent touched much with lightning or LOD in settings.

Now I can play for hours with no problem, as otherwise it would crash in almost every match..

if this is a "temporary fix" I think its a big breakthrough!

I think the key here might actually be Triple Buffered for some reason.. My friends with default settings are also ofc all using this too..

And they never had these "technical issue" crashes.

[eXe_NIBIRU]

First time ever I crashed in Apex, first game just after the 1.1.1 update. 400+hours played before.

I do have 8700k + 16gb ram DDR4 & 1080ti, overcloacked, oh and my cpu is'nt overheating, max 50° when limit is 80°..

log here :

crash:
{
R5Apex: 00000000002F2E2A
EXCEPTION_ACCESS_VIOLATION(write): 0000000000000653
}
cpu: "Intel(R) Core(TM) i7-8700K CPU @ 3.70GHz"
ram: 16 // GB
callstack:
{
KERNELBASE: 000000000008667C
ntdll: 00000000000A810B
ntdll: 000000000008FD56
ntdll: 00000000000A46AF
ntdll: 0000000000004BEF
ntdll: 00000000000A341E
R5Apex: 00000000002F2E2A
!!!unknown-module!!!: 000002883DED727C
}
registers:
{
rax = 260190 // 0x0003F85E
rbx = 0x000000A50DB6C240
rcx = 0
rdx = 4
rsp = 0x000000A50CC5FB10
rbp = 1601 // 0x00000641
rsi = 0x0000028956588D80
rdi = 1616 // 0x00000650
r8 = 0
r9 = 130155 // 0x0001FC6B
r10 = 447828 // 0x0006D554
r11 = 447828 // 0x0006D554
r12 = 448215 // 0x0006D6D7
r13 = 448215 // 0x0006D6D7
r14 = 1
r15 = 0x0000028848AE25F0
rip = 0x00007FF703B82E2A
xmm0 = [ [399924, 0, 0, 0], [0x48C34680, 0x00000000, 0x00000000, 0x00000000] ]
xmm1 = [ [1904400, 0, 0, 0], [0x49E87880, 0x00000000, 0x00000000, 0x00000000] ]
xmm2 = [ [1.440189, 0, 0, 0], [0x3FB8581D, 0x00000000, 0x00000000, 0x00000000] ]
xmm3 = [ [575966.13, 0, 0, 0], [0x490C9DE2, 0x00000000, 0x00000000, 0x00000000] ]
xmm4 = [ [1728357.9, 0, 0, 0], [0x49D2FB2F, 0x00000000, 0x00000000, 0x00000000] ]
xmm5 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm6 = [ [1728357.9, 0, 0, 0], [0x49D2FB2F, 0x00000000, 0x00000000, 0x00000000] ]
xmm7 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm8 = [ [2332.8899, 9331.5596, 3.4028235e+38, 3.4028235e+38], [0x4511CE3D, 0x4611CE3D, 0x7F7FFFFF, 0x7F7FFFFF] ]
xmm9 = [ [3.4028235e+38, 3.4028235e+38, 3.4028235e+38, 3.4028235e+38], [0x7F7FFFFF, 0x7F7FFFFF, 0x7F7FFFFF, 0x7F7FFFFF] ]
xmm10 = [ [0, 0, 0, 0], [0, 0, 0, 0] ]
xmm11 = [ [1, 0, 0, 0], [0x3F800000, 0x00000000, 0x00000000, 0x00000000] ]
xmm12 = [ [0.34999999, 0, 0, 0], [0x3EB33333, 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: 1554860081

[OrioStorm]

@Lunchb0x88, thanks for those crashes. I quickly went through them. They're all a little different from each other, but they're all in the same code function, and none of them should be possible with a properly functioning CPU.

4 out of the 9 are crashing at 2F2DCA. Of those, 1 says it hit a breakpoint, and 3 say they tried to write to address FFFFFFFFFFFFFF8C. The instruction there doesn't want to do either of those things.

3 out of the 9 are crashing at 2F2E2A. This is the most plausible crash; it might be explained by stack corruption. However, I've verified that this function can't corrupt the stack itself, and it only calls one other function. If that other function corrupted the stack, how did it not crash before returning here? That function is called from dozens if not hundreds of places. If it's corrupting the stack, why does it only crash here, and not any of those other places? So even this crash doesn't make sense.

1 out of the 9 is crashing at 2F2E9E while trying to write to memory address 1. The code never wants to execute an instruction at 2F2E9E, because that's in the middle of the instruction that starts at 2F2E99. The instruction at 2F2E99 is 8 bytes long, so 2F2E9E is 5 bytes into that instruction. If it did want to execute the middle of that instruction, it would crash this way with the registers in the log. But it should never want to crash this way.

1 out of the 9 is crashing at offset 2F20BB, loaded at address 0x00007FF6AC3520BB, while trying to execute memory at 0x00007FF600000000. Note that the instruction it's trying to execute is not the instruction it should be trying to execute; it is almost the right address, but the last half of the address has been forced to all zero.

This brings up an interesting point. The crash a 2F20BB was reported from the previous patch; all the other crashes are from the most recent patch. I saw the 2F20BB crash a bunch of times on the previous patch; I haven't seen it since then. On the other hand, all the other crashes people are getting with the latest patch are new; I never saw them on the previous patch.

Now, this function did change in this patch, but in a trivial way. If you know C++, all we did was we took a function that was an inline member function inside a struct, and we turned it into an inline function at global scope. The compiler should generate equivalent code for this change, but that's not guaranteed, and I haven't yet diffed the disassembly of the two patches to see whether it did.

So, our change shouldn't alter this function's behavior at all. And it didn't stop this particular function from crashing, but the nature of the crashes completely changed. Maybe the change to crash behavior is because the function is at a different offset in memory now? Now I'll have to go look at the old patch's disassembly and compare.

[OrioStorm]

@TEZZ0FIN0, do you know whether your friends have the same CPU? This crash appears to be Intel-specific, since none of the reports I've seen have been on an AMD CPU.

[OrioStorm]

@eXe_NIBIRU, that crash is the one where the CPU decides to execute an instruction starting in the middle instead of at the beginning (like one that @Lunchb0x88 just reported). A properly functioning CPU shouldn't be able to do that.

I'm not convinced that this problem is limited to overclocking, but it might be an exacerbating factor.

Overclocking can cause faults even without overheating. If you're overclocking, you're reducing the time the CPU is allowed to take for each step of each instruction, but the transistors still toggle at the same speed as they execute each stage. If the clock is ever shorter than a step of an instruction, the next step of the instruction can start before the previous step's results are done.

As an analogy, imagine you're doing a 10-digit addition problem, and somebody else is going to use your answer. Normally, they give you enough time, and you get all 10 digits before they look at it. However, if they're in a hurry (as in overclocked), they may look at your answer when you've only written down the first 8 digits. They don't see the problem you're working on, only your answer, so they use those 8 digits as if it was the correct answer, when it's not - it's just part of the answer. So anything they do with that number is likely to be wrong.

Overclocking and overheating can both cause rare CPU errors. You can get errors from overheating without overclocking, and you can get errors from overclocking without overheating. If you're both overclocking AND overheating, that's really pressing your luck!

Again, I don't know whether this is due to overclocking or not, but I do know that none of these crash reports seem possible with a properly functioning CPU.

[Falkentyne]

I absolutely need everyone who is crashing at stock CPU speeds to disable Spectre and Meltdown protection as per my above post last page, and see if that helps stability.

If there is a bug in the Intel microcode, Intel needs to hear about it.  (This is only for current updated versions of windows).  I'm still seeing people post crash reports and 0 people attempting to do what I suggested just in case.  As I said, Intel pulled older Kaby/Coffee series microcodes before because they were actually destroying chips...(9900k and 9700K were not released yet).