[PC] VRAM Never Released Between Matches – GPU Stalls at 4GB Limit Every Time

Hi,

I've been playing FC26 since October 2025 and for the first two months everything was perfect — no issues at all. Then in late November 2025 the game became nearly unplayable and I've spent a significant amount of time trying to understand why. I want to share everything I've found, because what started as a frustrating gameplay problem turned into a fairly deep technical investigation, and I think the data I've collected might genuinely help your team identify the exact source of the issue.

I should mention upfront that I work as an industrial engineer. My background is in process analysis, measurement systems, and root cause investigation — so when something doesn't behave the way it should, my instinct is to measure it, eliminate variables one by one, and not stop until the data tells a clear story. That's what I did here.

HOW IT STARTED

My system: MSI Katana GF76 11UC laptop, Intel Core i7-11800H, NVIDIA GeForce RTX 3050 Laptop GPU with 4GB VRAM, 32GB system RAM, Windows 11 Pro, FC26 via Steam.

From October through late November 2025, I played regularly with no performance issues. Then the stuttering began. FPS would drop from a stable ~60 to somewhere between 0 and 7 mid-match, and would stay there for the rest of the session. The game never crashed and never showed an error message — it simply stopped being able to render at normal speed. The only way to recover was to close and restart the game.

My first hypothesis was a Windows update. The timing matched — a cumulative update had arrived around the same time the problem started. So I went down that path systematically. I rolled back to an earlier Windows 11 24H2 build (26100.1742, the original release of 24H2). I tested two different NVIDIA driver versions: 565.90 and later 595.x. I eventually did a full clean format — wiped the drive, reinstalled Windows from a fresh ISO, reinstalled Steam, reinstalled FC26 from scratch. Nothing changed. The stutter came back every single time, behaving identically.

That result was actually the first meaningful data point: if a complete system reinstall doesn't fix the problem, the problem is not in the system. It's in the one thing that reinstalling can't undo — the game itself, which Steam always updates to the latest version automatically.

For context: Age of Empires 4 on ultra settings runs without any issues on this machine. Every other game I tested runs normally. Only FC26 exhibits this behavior.

MEASUREMENT METHODOLOGY

I recorded hardware monitoring sessions using MSI Afterburner with the following metrics active simultaneously: GPU usage (%), GPU Frame Buffer usage (MB), GPU memory usage (MB), GPU core clock (MHz), GPU memory clock (MHz), GPU power draw (W), GPU temperature (°C), CPU temperature (°C), CPU clock (MHz), CPU power (W), system RAM usage (MB), RAM usage per process (MB), framerate (FPS), frametime (ms), 1% low FPS, and 0.1% low FPS.

The primary session I'll reference here lasted 48.8 minutes, recorded on 16/03/2026 between 01:59 and 02:47, and captured 2,928 individual data points at approximately one-second intervals. The session covered desktop idle, then two Kick-Off matches played without incident, followed by one Ultimate Team match during which the stutter began mid-match and persisted until I ended the recording.

A second session was recorded after upgrading to Windows 11 25H2 and NVIDIA driver 595.x, under identical test conditions, to measure whether the newer software stack changed the behavior in any direction.

WHAT THE DATA SHOWS

Let me walk through what the numbers actually say, because this is where it gets specific.

VRAM ALLOCATION ACROSS THE SESSION

At session start (desktop, before launching FC26): 134 MB VRAM in use.

The moment FC26 loaded, VRAM jumped immediately. By the 5-minute mark, VRAM was already at approximately 3,333 MB. By the 10-minute mark it was at 4,068 MB — within 28 MB of the hardware ceiling of 4,096 MB. From that point forward, VRAM stayed above 4,000 MB for the remainder of the session.

What did not happen at any point: VRAM did not drop between matches. Not after the first match ended, not after the second. Each match added to the cumulative total and none of it was released. The progression looks like a one-way ramp, not a usage curve with natural peaks and valleys.

NORMAL GAMEPLAY METRICS (pre-stutter):

- Average FPS: 59.6

- GPU core clock: 1,900–1,965 MHz

- GPU power draw: 55–58 W average

- GPU temperature: peak 71°C

- CPU temperature: peak 76°C

- GPU Frame Buffer: 14–16 MB available (shrinking gradually)

- GPU usage: 46–51%

- All values within normal operating parameters

STUTTER ONSET — EXACT TRANSITION POINT

At 02:38:51 (39 minutes into the session), everything was still normal: 60 FPS, GPU at 47%, core clock at 1,942 MHz, GPU temperature 70°C, VRAM at 3,880 MB, Frame Buffer at 15 MB.

Three seconds later, at 02:38:54: FPS dropped to 30, then to 25, then within two seconds to 5.6. GPU usage spiked to 100%. Frame Buffer collapsed from 15 MB to 0 MB.

From that point forward, for the next 49 minutes until I closed the recording:

- Average FPS: 5.7 (minimum: 0.0)

- Average frametime: 201 ms (maximum recorded: 1,721 ms)

- GPU Frame Buffer: 0.7 MB average, 4 MB maximum — functionally zero

- GPU usage: consistently 99–100%

- GPU core clock: stable at 1,935–1,965 MHz — no reduction

- GPU temperature during stutter: 64–66°C — actually lower than during normal play

- GPU power draw during stutter: 41–43 W

This is a critical observation. The GPU did not throttle. Clock speed did not drop. Temperature went down, not up. Power draw decreased slightly. The GPU was working as hard as it could — but there was no Frame Buffer space left to write rendered frames into. It was running at full capacity with nowhere to put the output.

I also checked Windows Event Viewer for the exact time window of the stutter (02:38 to 02:47). There were zero GPU-related errors, zero DirectX errors, zero display driver events of any kind. From Windows' perspective, nothing went wrong. The system was functioning normally. Only FC26 was not.

SECOND TEST — WINDOWS 25H2 + NVIDIA 595.x

To verify whether the updated software stack changed anything, I ran an identical test session after upgrading both Windows and the NVIDIA driver to their latest versions as of mid-March 2026.

The outcome: the stutter occurred again, with identical characteristics. However, there was a notable difference in the rate of VRAM consumption. In the first session, VRAM reached 4,000+ MB around the 10-minute mark. In the second session, VRAM reached 4,068 MB within the first 5 minutes — before any match had even fully loaded. The newer NVIDIA driver appears to allocate VRAM more aggressively upfront, which means on 4GB hardware the window before stutter onset is even shorter than before.

DIFFERENTIAL DIAGNOSIS — WHAT THIS IS NOT

Because I tested systematically across multiple configurations, I can state the following with confidence:

Thermal throttling: eliminated. GPU temperature is normal throughout and actually drops during the stutter event. If throttling were occurring, clock speed would decrease. It does not.

Power limit throttling: eliminated. GPU power draw is within normal range before, during, and after the stutter. No power limit events recorded.

Driver issue: eliminated. Tested on NVIDIA 565.90 and 595.x. Identical behavior on both. The problem predates and survives driver changes.

Windows version issue: eliminated. Tested on Windows 11 24H2 (build 26100.1742) and 25H2. Identical behavior on both. The problem survives OS changes.

Hardware fault: eliminated. Every other game tested on this machine runs without issues, including GPU-intensive titles on maximum settings.

Clean reinstall: does not fix it. Full format, fresh OS, fresh game install — stutter returns within the same session. This rules out any corrupted local file or configuration as the cause.

The single variable that cannot be changed is the game version. Steam installs whatever the current version is. The problem follows the game, not the system.

ROOT CAUSE

The data points to one conclusion: FC26 allocates VRAM during match loading and does not release it when the match ends. Each subsequent match adds to the cumulative allocation. When the total reaches the hardware limit of 4,096 MB, the DirectX 12 Frame Buffer has no remaining space to allocate, and the render pipeline effectively stalls — producing 0–7 FPS despite the GPU running at full clock speed.

This is a memory management failure in FC26's DirectX 12 implementation, most likely within the Frostbite engine's resource deallocation path between match sessions.

I want to be precise about what the data does and does not show. The data shows that VRAM fills and is never released. It does not tell me whether the allocated blocks are still being actively referenced by the engine or whether they are orphaned allocations that the engine has lost track of. Both would produce the same observable behavior from outside the process. Your team's internal tooling would be needed to distinguish between those two cases — but either way, the fix is the same: VRAM needs to be released when a match ends.

TWO ADDITIONAL OBSERVATIONS

First, regarding the strand-based hair rendering bug reported on this forum: in my case, strand-based hair rendering was already disabled. I play on medium graphics settings, and that feature is off by default at that preset level. Despite this, the VRAM leak occurs at the same rate. This means strand-based hair is either one of multiple leak sources, or it is not the primary cause on medium settings. Either way, disabling it is not sufficient on its own.

Second, regarding the scope of affected hardware: this issue is often discussed as a "4GB VRAM problem," but I don't think that framing is accurate. The leak itself appears to be hardware-agnostic — it's the 4GB ceiling that makes it visible quickly. A system with 6GB or 8GB VRAM will fill up more slowly, but given the rate of allocation I measured, it will still fill up within an extended session. The difference is time-to-failure, not whether failure occurs. This means the affected player population is broader than the 4GB segment alone.

WHY NOVEMBER

I played for two full months without any issues. The stutter appeared in late November 2025 and has been present in every session since, regardless of system configuration changes. The only element that changed during that period and cannot be reverted is FC26 itself. Steam updates the game automatically and there is no official way to roll back to a previous game version. Whatever was introduced in the November 2025 update — whether a new feature, a rendering change, or a regression in the resource cleanup path — has not been present since.

I'm aware that FC25 had a similar issue that appeared around November 2024 and was resolved by a patch in January 2025. I hope the same timeline applies here.

WHAT I'M ASKING FOR

I'm not looking for a workaround. Restarting the game every few matches is not an acceptable long-term solution for a paid product. What I'm asking for is a fix to the VRAM deallocation path so that GPU memory is properly released when a match session ends, allowing the next match to begin with a clean memory state.

The data I've described is precise, reproducible, and collected under controlled conditions across multiple test sessions. If the raw Afterburner log files would be useful to your engineering team, I'm happy to provide them.

Thank you for reading this far. I realize this is a long report — but I figured if I was going to file a bug report, I might as well make it one that's actually useful.

EA account: ozanyilmaz08

Background: Industrial Engineer

System: MSI Katana GF76 11UC | Intel Core i7-11800H | NVIDIA GeForce RTX 3050 Laptop GPU 4GB VRAM | 32GB RAM | Windows 11 25H2 | NVIDIA Driver 595.x | FC26 via Steam (latest version as of March 2026)