Crash after Mass Sub Backups (PC/Steam): same fault in 10/10 crash dumps
[PC/Steam] Crash to desktop after Mass Sub Backups: same overflow at index 49,280 in 10 of 10 crash dumps across four builds, still happening on the current build
The crash to desktop after using Mass Sub Backups is still happening on PC as of today (November 15) on the current build. I've also gone through my crash dumps, and the results point to a single, specific bug in the game. I'm hoping this gets it in front of the right engineers.
Today's crash, on the current build: In Dynasty with 15-minute quarters, I used Mass Sub Backups at halftime, and the game crashed to desktop in the 3rd quarter, about 37 minutes after launch. No crash dump, Application Error event, or Windows Error Reporting entry was recorded for this crash. The only related System log entries were the EAAntiCheat filter and service unloading, so I can't confirm from diagnostics that it's the same fault on this build, but the trigger and timing match the 10 dumped crashes exactly.
What the earlier dumps show: I have dumps from 10 crashes between August 11 and October 3, covering four game builds. Every one is an access violation (0xC0000005) inside CollegeFB27.exe itself, a write to address 0x0. The faulting instruction is mov qword ptr [rcx+rbp*8], rbx. Here rcx is a chunk pointer read from a chunk table, and it is null. The code splits an index into chunk = index >> 7 and slot = index & 127, so this is a paged array of 128-entry chunks. In all 10 crashes the index is exactly 0xC080 (49,280): chunk 385, slot 0, the first slot of the 386th chunk. The container appears to have 385 allocated chunks (49,280 entries), and adding the 49,281st entry writes through a chunk pointer that was never allocated. The entry being inserted is a 72-byte object allocated just before the write.
Faulting address by build (exe link timestamp, UTC):
- Jul 31 build: CollegeFB27.exe+0x51b708d
- Aug 14 build: CollegeFB27.exe+0x51b708d
- Aug 20 build: CollegeFB27.exe+0x51bb3dd
- Sep 28 build: CollegeFB27.exe+0x51b87dd (first return address on the stack: +0x51ea485)
Every crash, today's included, came 31 to 41 minutes after launch. This is not memory exhaustion: system commit headroom at the time of the crashes ranged from 2.7 GB to 7.6 GB, and a failed allocation wouldn't produce the identical index every time. My working theory is that this container fills up over the course of a game and the burst of new players from a mass sub pushes it past its fixed capacity. That would explain why today's crash came in the 3rd quarter after a halftime mass sub, and why others on this forum say shorter quarters or simming the rest of the game after a mass sub avoids it. It would also explain console players reporting the same crash, since this is game code rather than anything specific to PC hardware.
Steps to reproduce:
- Start a Dynasty game (I use 15-minute quarters).
- Use Mass Sub Backups (at halftime or in the 4th quarter).
- Keep playing. The game crashes to desktop within a few drives to a quarter, roughly 31 to 41 minutes after launch.
System: Steam version 1794536281; Windows 11 26H2 (build 26300); AMD Ryzen 5900X, 24 threads; Nvidia GeForce RTX 3080; 32 GB RAM.
This is the same issue as reported in this thread: https://forums.ea.com/discussions/college-football-27-technical-issues-en/game-freeze-and-crash/13629187
I'm happy to share the raw .dmp files with EA staff if that would help.
