This bug has been reported since 2014 and has never been triaged, because every diagnostic Epic has ever asked for returns a clean result. I found the actual cause and a working mitigation. Posting full details so it can finally be fixed.
Read this first if you’re staff
Do not ask for powercfg /requests. It shows None in every category, always, while the bug is actively occurring. This is not a power request. The launcher is resetting the Windows user-idle timer (GetLastInputInfo) roughly every 2 seconds, which keeps the display-off and sleep timers permanently at zero. That is why 11 years of powercfg screenshots have shown nothing, and why in-house repro attempts have failed.
Cause
The trigger is an attached HID game controller with an analog axis that rests at its extreme.
In my case that’s a Thrustmaster TWCS Throttle (VID_044F&PID_B687). Two of its axes never sit near center:
Z— the throttle lever. A throttle rests at minimum by design. Reads65535.V— a phantom axis, probably reserved for e.g. rudder pedals, pegged at65535that no physical control on the device drives at all. I swept every control on the unit; nothing moves it. It cannot be centered, and calibration will not fix it.
The launcher sees a controller axis deflected hard over, concludes the user is actively holding an input, and suppresses the screensaver/idle timeout continuously and forever, because the axis never returns to center.
This is why it reproduces on sim hardware and essentially nowhere else. Your test machines don’t have a HOTAS plugged in.
Verification (controlled A/B, Windows 11 build 26220, Launcher 20.2.9-0+UE5)
| Condition | Windows idle timer |
|---|---|
| Launcher running, throttle connected | pinned at 0 s indefinitely |
| Launcher fully closed | counts up normally |
| Launcher running, both Thrustmaster devices disabled | counts up normally |
| Launcher running, throttle only disabled | counts up normally |
| Launcher running, joystick only disabled (T.16000M, rests centered) | pinned at 0 s |
The T.16000M is the control case: it rests centered, so it never triggers this, even though it is the same brand on the same machine. That isolates the fault to axis rest position, not to the vendor or the driver.
Mechanism
It is not FAnalogCursor. I parked the mouse pointer and logged its coordinates alongside the idle timer: the cursor never moved by a single pixel while the idle timer was being reset every ~2 s. So nothing is calling SetCursorPos.
The signature matches the zero-pixel SendInput(MOUSEEVENTF_MOVE, dx=0, dy=0) screensaver-inhibitor pattern, i.e. the PreventScreenSaver() / FScreenSaverInhibitor style path. It resets the idle timer while leaving the pointer stationary, and it creates no power request, which matches every observation above.
This also explains why the code exists: raw HID/joystick input does not reset the Windows idle timer on its own (documented GetLastInputInfo behavior tracks keyboard and mouse only). So a controller-driven UI has to inhibit the screensaver deliberately. The logic is reasonable; the bug is that a permanently-deflected axis is treated as sustained user activity instead of as a resting state.
-NoGamepad is accepted and then ignored
This is the concrete engineering detail I’d most like looked at. I launched with:
EpicGamesLauncher.exe -NoGamepad
I confirmed via WMI that the flag survives the launcher’s self-relaunch and is present in the command line of the running process (the launcher re-execs itself with -EOSBootstrappedFlag -ForcedRestart, so I checked the final process, not the one I started). The idle resets continued unchanged.
In the engine, -NoGamepad sets bForceNoGamepads and short-circuits PollGameDeviceState() entirely. In the shipped launcher it has no effect. Either the launcher doesn’t route through that path or it’s overridden somewhere downstream.
Suggested fixes, in order of preference
- Treat a stationary axis as idle. Inhibit the screensaver on axis change, not on axis position. An axis that has not moved in N seconds is not user activity, regardless of where it’s sitting. This is the correct fix and it’s small.
- Make
-NoGamepadactually work in the launcher, and/or expose a “disable controller input in the launcher UI” setting. There is currently no user-facing option for this anywhere. - Don’t inhibit the screensaver when the launcher has no focus / is minimized to tray. The launcher sitting in the tray has no business holding the display awake at all.
Impact: this is causing hardware damage
Multiple users in the existing threads report permanent monitor damage from displays being held on for days:
- Epic Launcher won’t let my monitor sleep - Development / Programming & Scripting - Epic Developer Community Forums
- Ongoing Problem with Epic Games Launcher Preventing Screen to go off while downloading or updating. PLEASE EPIC GAMES FIX THIS - General / Feedback & Requests - Epic Developer Community Forums
OLED panels are now common on desktops and laptops. A background tray app silently defeating display-off is a burn-in vector. That moves this out of “annoyance” territory.
Workaround for other users, today
Until this is fixed, use HidHide (free, open source, nefarius/HidHide: Gaming Input Peripherals Device Firewall for Windows.) to hide the offending controller from the launcher specifically, while every game keeps full access to it:
- Install HidHide.
- In the Devices tab, tick your throttle/HOTAS.
- In the Applications tab, add
EpicGamesLauncher.exe(both of these):C:\Program Files\Epic Games\Launcher\Portal\Binaries\Win64\EpicGamesLauncher.exeC:\Program Files\Epic Games\Launcher\Engine\Binaries\Win64\EpicGamesLauncher.exe
- Enable Inverse application list (this flips the list from “allow” to “deny”, so you deny Epic only instead of whitelisting every game you own).
- Enable cloaking.
Gotcha that will make you think it failed: HidHide’s filter only attaches to device stacks created after the driver was registered. Right after installing, cloaking silently does nothing. Either reboot, or open Device Manager and disable + re-enable the device’s USB container entry to force the stack to rebuild. After that it takes effect immediately.
Confirmed working: with the throttle hidden from the launcher only, the launcher runs normally, every game still sees the throttle, the idle timer counts up correctly, and the monitor powers off on schedule.
Things that do NOT work, so nobody wastes more time
powercfg /requests— always clean. Wrong tool for this class of bug.- Recalibrating the controller — a throttle’s rest position genuinely is an extreme; and the phantom
Vaxis isn’t bound to any physical control, so nothing you do with your hands will center it. -NoGamepad— accepted, ignored (above).- “It only happens while downloading” — false. Zero download or update activity here; it reproduces on a fully idle launcher sitting in the tray.
- Killing
explorer.exe, setting sleep to Never, remapping the power button, running some unrelated app as admin, NirCmd blankers — these are workarounds for the symptom that have accumulated in the old threads. None address the cause.
Happy to supply raw logs, per-axis dumps, or test any build.