Your controller is connected at the Windows level but effectively disconnected at the game level, because Apex Legends and its anti-cheat (Easy Anti-Cheat) enumerate input devices through a separate API path than the one Windows uses to confirm "connected." When the game boots, it queries XInput and Raw Input interfaces fresh and applies its own device-class filtering. If that handshake fails or the device is claimed by another process, the game ignores the controller until you physically replug it. That replug forces a re-enumeration the game then catches.
The enumeration gap between Windows and Apex
Windows reports a controller as connected when the driver loads and the device appears in Device Manager and the Game Controllers panel. That confirmation can come through several routes: XInput, DirectInput, HID, or a vendor driver. Apex, built on a Source-family engine with Steam Input and Easy Anti-Cheat layered on top, does not simply read "connected" from Windows.
At launch, the game opens its own input handles. It polls XInput slots 0 through 3 for the Xbox-compatible path. It also reads Raw Input for keyboard, mouse, and some gamepads, then reconciles them through its own device mask. If the controller was already claimed by Steam's overlay, by a background remapper, or by a second copy of the game's input hook, the fresh XInput query can return an empty or "not connected" state. The game then defaults to keyboard and mouse until a physical disconnect-reconnect event fires, which resets that enumeration.
Replugging works because it triggers a device-arrival notification. Apex listens for that signal and re-reads the slot. Without a new arrival event, it never retries. This is why the controller "works in Windows" but "doesn't work in Apex" until you unplug and plug it back in. The OS was never the problem.
Quantifying the handshake
The timing windows are tight and explain most intermittent cases. A standard USB controller enumerates in roughly 100 to 500 ms after plug-in. XInput polling runs at 60 to 1000 Hz depending on driver, but Apex samples input per frame, targeting 60 to 240 frames per second. Steam Input, when active, adds a translation layer that can introduce 1 to 4 ms of latency and, more importantly, can hold the HID handle exclusively.
Easy Anti-Cheat adds a check at match start and at process initialization. It verifies that input DLLs and device handles match what the game expects. A device that appears mid-session, or one whose handle changed, can be flagged internally and suppressed rather than crashing. The practical threshold is the launch sequence: everything must be enumerated and claimed within the first few seconds of the game process starting.
Wireless controllers widen the window. Bluetooth pairing keeps a device "present" in Windows even when the radio link is idle, so the OS shows connected while Apex's XInput read sees nothing until a button press wakes the link. That wake can take 200 ms to 2 seconds, longer than the game's input initialization. Wired USB-C and the Xbox Wireless Adapter behave differently from plain Bluetooth, which is why the same controller works on one connection and fails on another.
A launch-sequence timeline
| Phase | What happens | Typical duration | Failure symptom |
|---|---|---|---|
| Driver load | Windows registers the controller | 100–500 ms | Device missing in Game Controllers |
| Link wake | Bluetooth or adapter link goes active | 200 ms–2 s | Windows shows connected, no input |
| Steam Input layer | Optional remap and handoff | 1–4 ms added | Double input or no input |
| Game process start | Apex opens XInput and Raw Input handles | 0.5–2 s | Controller ignored at menu |
| Easy Anti-Cheat check | Validates input DLLs and handles | 1–3 s | Silent suppression |
| Match start | Re-query of input devices | Per match | Works in lobby, fails in match |
| Physical replug | Device-arrival event fires | 100–500 ms | Input returns |
Edge cases that break the pattern
Steam Input is the most common edge case. When Steam Input is set to "Xbox Configuration Support" or a per-game template is forced, Steam intercepts the controller and presents a virtual device to the game. Apex can end up seeing both the physical and virtual device, or neither if the handoff fails. The fix is usually toggling Steam Input off for Apex specifically, not globally.
A second edge case is the "hidden" second controller. Controllers left paired to a Bluetooth dongle, a dusty Xbox 360 receiver, or a phone can occupy an XInput slot. Apex reads slot 0 first; if an idle device sits there, the active controller in slot 1 may be ignored until re-enumeration. Unpairing unused devices resolves this.
Wireless adapter firmware and USB port power management are quieter culprits. Windows can suspend a USB root hub to save power, and the controller's handle goes stale without a disconnect event. A replug resets the hub state. Finally, some controllers ship in DirectInput mode by default (many 8BitDo and generic pads); Apex expects XInput for its primary path, so a mode switch at the hardware level is required before the game will bind it reliably.
Misconceptions worth retiring
The most persistent myth is that a controller "doesn't support Apex." Apex supports Xbox and PlayStation-style controllers natively, and most well-known third-party pads work once the input mode is set correctly. The problem is almost always enumeration and claiming, not compatibility.
A second misconception is that reinstalling the game fixes it. Reinstalling resets files but does not change device claiming at launch. A third is that the Windows Game Controllers test proves the game will see the pad. That test confirms the driver, not the game's XInput slot state.
Professional caveat: a controller that reconnects only after a replug is functioning normally from a hardware standpoint. The failure is a race condition in the launch handshake. Treating it as a hardware defect leads to unnecessary returns.
Practical actions and thresholds
Work through these in order; stop when input survives a full game restart without a replug.
Verify input mode: confirm the pad is in XInput mode (usually a switch or button combo), then check it appears in Windows "Set up USB game controllers." Disable Steam Input for Apex only: Steam > right-click Apex > Properties > Controller > set to "Disable Steam Input." Restart the game and test. Unpair idle controllers: remove unused Bluetooth and adapter devices so only one pad occupies XInput slots. Disable USB selective suspend for the controller's root hub in Device Manager, and turn off "Allow the computer to turn off this device to save power." Prefer wired USB-C or the official Xbox Wireless Adapter over generic Bluetooth for Apex; the link wake is more reliable under the game's tight initialization window. If using a third-party remapper, close it before launch and confirm no virtual controller is active.
A useful threshold: if input returns within 500 ms of replug, the enumeration path is healthy and the launch race is the cause. If it takes longer or never returns, suspect a driver or input-mode problem first.
What this cannot fix
Some failures sit outside user control. Easy Anti-Cheat updates can change how input handles are validated, and a game patch can alter the launch sequence overnight. On those days, the replug workaround is the practical answer until the developer ships a fix.
Bluetooth stacks on certain motherboards and laptops are also unreliable under load, and no game-side setting corrects a flaky radio. Likewise, cloud gaming and remote-play sessions introduce their own input virtualization that can defeat local enumeration entirely. The mechanism is sound; the environment is the variable.
If you have tried the steps above and the controller still requires a replug every launch, document the exact sequence (connection type, Steam Input state, one or multiple pads) before contacting support. That record distinguishes a genuine driver conflict from the ordinary launch handshake race that a replug resolves.