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.
EA Staff (Retired)@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.
Community Manager
