[PC / AMD] FSR Frame Generation causes persistent black screen on subsequent launches — reproducible via cvars.xml
[PC / AMD] FSR Frame Generation causes persistent black screen on subsequent launches — reproducible via cvars.xml
Platform: Steam / Windows 11
System specifications:
-
CPU: AMD Ryzen 5 9600X
-
GPU: ASUS Radeon RX 9060 XT OC 16 GB
-
RAM: 32 GB DDR5-6000
-
GPU driver: Latest AMD Adrenalin driver 26.10.1
-
OS: Windows 11
Issue description
I've encountered a reproducible startup issue with Marathon that appears directly related to AMD FSR Frame Generation and how its enabled state is restored from the game's configuration file.
Marathon launches and runs normally with FSR Frame Generation disabled. I can enable frame generation from the graphics menu and play for several hours without encountering any noticeable problems.
However, after closing Marathon normally and launching it again, the game becomes permanently stuck on a black screen before displaying any Bungie, PlayStation, or other startup logos.
The process remains running indefinitely without crashing or displaying an error.
Initially, I suspected HDR because the problem first occurred immediately after enabling Windows HDR. However, further testing isolated FSR Frame Generation as the relevant configuration setting.
Steps to reproduce
-
Start Marathon with a fresh configuration, or with FSR Frame Generation disabled.
-
Confirm that the game launches normally.
-
Enable AMD FSR Frame Generation in the graphics settings.
-
Play the game normally. In my case, I was able to play for several hours without issues.
-
Exit Marathon normally.
-
Launch Marathon again.
-
The game becomes stuck on a black screen before any startup logos appear.
The issue has occurred repeatedly on my system, although I cannot confirm that it reproduces on every machine or with every AMD driver.
Actual result
Marathon becomes indefinitely stuck on a black screen immediately after launch.
While monitoring the process through Windows Task Manager, I observed:
-
CPU utilization: Approximately 8–8.5%, consistently.
-
Memory utilization: Approximately 2 GB, remaining stable.
-
GPU utilization: Effectively 0%, with negligible activity.
-
Process state: Remains running rather than terminating.
-
Error messages: None displayed.
The CPU usage corresponds to roughly one fully occupied logical processor on my 12-thread CPU, suggesting that the process may be continuously executing an initialization routine without progressing to rendering.
This is only an observation; I cannot determine the specific thread or subsystem responsible.
Expected result
Marathon should initialize and display the startup logos and main menu normally, regardless of whether FSR Frame Generation was enabled during the previous session.
If frame generation cannot initialize successfully, the game should ideally fall back to a supported rendering configuration rather than becoming indefinitely unresponsive.
Confirmed workaround / configuration isolation
After troubleshooting, I was able to isolate the issue to a single configuration parameter.
The affected configuration file is located at:
%APPDATA%\Bungie\Marathon\prefs\cvars.xml
Under the graphics namespace, the following parameter is present when frame generation is enabled:
<cvar name="frame_generation_mode" value="2" />Changing only this value from 2 to 0 completely resolves the startup issue:
<cvar name="frame_generation_mode" value="0" />After saving the XML file, Marathon launches normally again.
Crucially, no other preferences need to be changed. All other graphics settings, key bindings, and user preferences can remain intact.
Deleting the entire preferences directory also restores startup, but this is unnecessary once the problematic parameter is identified.
This strongly indicates that the saved frame-generation state is triggering a failure during startup initialization.
It does not necessarily mean that the frame-generation implementation itself is malfunctioning during gameplay, since the feature works successfully once the game has initialized.
Troubleshooting already performed
-
Completely uninstalled and reinstalled Marathon through Steam.
-
Restarted Windows multiple times.
-
Disabled Windows HDR after initially suspecting an HDR-related issue.
-
Deleted the existing Marathon preferences and allowed the game to regenerate them.
-
Successfully launched and played Marathon for several hours after regenerating preferences.
-
Re-enabled AMD FSR Frame Generation.
-
Reproduced the black-screen startup issue following a subsequent normal exit.
-
Monitored CPU, GPU, and memory utilization during the hang.
-
Edited only
frame_generation_modefrom2to0. -
Confirmed that this single modification restores normal startup.
I have not yet tested clearing the AMD shader cache or rolling back to an earlier AMD driver.
Possible technical explanation
My suspicion is that Marathon encounters an initialization or compatibility problem when restoring an already-enabled FSR Frame Generation configuration at startup.
There appears to be a distinction between:
-
Enabling frame generation after the graphics renderer has successfully initialized, which works correctly.
-
Initializing the game with frame generation already enabled in the saved configuration, which results in a permanent black screen.
Given the negligible GPU utilization and persistent CPU activity, this could involve a CPU-side initialization loop or synchronization issue before the renderer successfully begins submitting frames.
This is speculative, however, and would require investigation by the development team.
I've also come across reports from other AMD users describing similar frame-generation-related startup problems, including reports that reverting to an earlier AMD driver resolves the issue. This suggests a possible driver compatibility component, although I have not independently verified that workaround.
Request
Could the development team investigate the startup initialization path when frame_generation_mode="2" is present in the saved graphics configuration, particularly on AMD Radeon RX 9000-series GPUs?
It may also be worth implementing a fallback mechanism so that a failed frame-generation initialization does not prevent the entire game from starting.
I'm happy to provide the problematic cvars.xml, system diagnostics, or additional reproduction details if useful.
Comments
Hi there,
Thank you for reaching out and for reporting this.
Could you provide a short video showing Marathon relaunching into the black screen with Task Manager visible?
Please use your platform's capture button to take a video. You can upload the footage to a public video hosting site, like YouTube, then post the link here, and we’ll be glad to take a look.
https://youtu.be/EoN0LCpPBcY
I've recorded a video with a voice-over that reproduces the bug in detail.
Please see the YouTube link above.
Hi again,
Thank you for the video.
We have taken note of your report and will pass it onto the dev team for further investigation
Thank you again for taking the time to alert us to this and for sharing such a detailed report.
In my case turning on AMD frame generation caused an immediate crash and subsequent attempts to reopen Marathon cause a brief black screen followed by a crash. When looking at xml file the frame generation mode setting is still set to 0. Changing it to 2 and then back to 0 has no effect. Having to uninstall and reinstall. Other than the crash upon changing the setting in game and crashing at black screen, the black screen is identical to zerocore's video.
Windows 11
26.10.1 AMD drivers
64GB DDR4-3600C18
AMD Ryzen 7 5800X 8-Core Processor
AMD Radeon RX 7800 XT
edit: Reinstallation has not fixed the problem and launches black screen then crashes.
Clearing driver cache did not fix.
Rolled back the drivers to 26.9.2 and the game now launches again and runs.
The new AMD driver is the problem. Roll it back and it works fine. The funny thing is, AMD finally made framegen much smoother with the latest drivers, and it works great in other games. On a side note, hope they fix scope artifacting when using framegen too
Please sign in to leave a comment.