I havent really had a use for my OpenAI quota recently so I had Astra do some static analysis on the June and current retail clients. It found some differences in how the overlay dlls are being hooked afaict, and it built a minimal test harness to try and validate its findings. In concert with a valve engineers comments seems like a possible avenue for exploration for fixing the steam frame pacing issue. Im hoping given the recent discussion about unvaluting a fix for this could make it into the game. I tried to have Opus cleanup the prose but kept getting flagged by classifiers. ------------ This is not a confirmed root cause; it identifies a particular interaction that could be checked on your side. What the offline comparison found Destiny selectively filters Steam-overlay requests for Windows loading functions. In the tested state, an overlay request for LoadLibraryExW was denied, while a request for the lower-level loading function LdrLoadDll was permitted. Selected ordinary-game requests still worked. The examined Steam overlay versions differ. The older captured renderer, 10.72.33.79, had no LdrLoadDll hook attempt in its initialization path, and the captured Windows function entry was unpatched. The newer official Windows renderer, 11.15.70.27, adds that installation attempt. The additional hook can perform synchronous scanning. Its wrapper can call Steam’s module scanner before returning control to the thread that requested the load. If that work is substantial and occurs on—or delays—a frame-critical thread, it could affect performance. The relevant lookup results matched in the old and current Destiny policy tests. The demonstrated difference is therefore the additional Steam interception attempt, not a newly demonstrated change to Destiny’s filtering. What remains unproven These were offline component tests with modeled Windows state, not a live gameplay benchmark. The old LdrLoadDll request was hypothetical because that renderer did not actually make it. The older capture is not an established good-performance baseline. Successful installation and execution of this hook during affected current gameplay, its scanning cost, and any isolated frame-time benefit remain unmeasured. The wrapper tests observed the scanner-call boundary, not execution of the scanner itself. Could the engineering team check: Whether Destiny’s filter is active when Steam initializes, which older loading hooks are installed, and whether the LdrLoadDll hook actually runs during affected gameplay. Whether work or waits on that path materially delay frame delivery. Whether a vendor-controlled comparison isolating only this overlay interception, with security controls and other functionality unchanged, produces a repeatable improvement. Any production change would also need separate overlay, Steam Input, recording and graphics-discovery validation. This is a request for vendor investigation, not a suggested player-side patch. Current Destiny build examined: 25932352. For context, Valve previously reported an overlay-update/anti-cheat CPU interaction and said it had contacted Bungie. That statement does not establish this particular mechanism: https://steamcommunity.com/groups/SteamClientBeta/discussions/0/589559717132703835/#c525387040750104743 I can provide the detailed offline results, exact file identities, relevant code locations and methodology limitations if useful.