Troubleshooting

Symptoms first, fixes underneath. In most cases the Doctor page already knows what's wrong — check there before working through this list manually. If nothing here helps, export a support bundle from Diagnostics and open a feedback report.

Windows 11 The app won't start at all

If the Windows installer ran fine but double-clicking the FFB-Bridge shortcut does absolutely nothing — no window, no error, no SmartScreen prompt — you're almost certainly running Windows 11 with Smart App Control (SAC) enabled. SAC silently blocks any app that isn't code-signed by a trusted publisher. The beta builds aren't signed yet (it's on the 1.0 roadmap), so SAC refuses to launch them.

The fix is to turn Smart App Control off long enough to install and first-run the app. Recent Windows 11 cumulative updates also let you turn SAC back on afterwards without reinstalling Windows — an improvement over earlier releases where toggling off was permanent. Microsoft's own guidance:

Microsoft: Smart App Control frequently asked questions

Once SAC is off, the FFB-Bridge app launches and, critically, keeps launching after you re-enable SAC — SAC only checks apps it hasn't seen before. So the workaround is one-time. Once code-signed installers ship with 1.0, this section goes away.

Stick doesn't move at all

Is it armed?

Open the Dashboard. The big toggle must be blue with the lightning glyph — if it's grey, click it. The sidebar's bottom-left pill also shows ARMED / DISARMED; make sure it's ARMED.

Is the device detected?

The Device chip under the Ready-to-engage banner on the Dashboard should be green. If not:

• Unplug and replug the stick; the bridge re-detects within a second or two.
• Confirm the VID/PID in your OS device manager (045E / 001B).
• Linux Doctor's udev-rule row should be green; if it's red, run the one-click installer.
• Windows Close any other app that claims force feedback — DIY testers, some joystick diagnostic utilities will hold exclusive access.

Is a sim connected?

The Sim chip should be green. If not, see the MSFS setup guide or the X-Plane setup guide for your sim. In the meantime, the Mock SimConnect page will let you confirm the rest of the pipeline is working.

MSFS connects but no forces feel right

If the stick is moving but the forces feel wrong, the problem is usually a profile or airframe mismatch:

• Start with the Cessna 172 starter profile. It's the known-good baseline. Most “wrong” feels come from a profile that was tuned for a different aircraft.
• Check the Dashboard's effect-active badges. If effects you didn't expect (like stall buffet) are firing, the sim is reporting unexpected telemetry — check Diagnostics for warning logs about missing SimVars.
• Third-party aircraft occasionally skip implementing standard SimVars. The bridge tolerates this (missing vars default to zero), but some effects will fail to fire as a result. This is a known limitation we can't easily work around in the bridge — report the specific aircraft so we can characterise.

Tray icon doesn't appear (Linux)

Some desktop environments don't ship a system-tray host out of the box — GNOME Wayland is the big one. When the bridge detects this, it shows a banner at the top of the window explaining that close will quit the app directly (instead of silently hiding), and the close button behaves accordingly. On GNOME install the AppIndicator Support extension to get a tray icon back; on KDE, Xfce, Cinnamon, MATE, and Budgie the tray works out of the box.

Doctor says SimConnect reachable but no data flows

The bridge is connecting (TCP hello is accepted) but the data stream isn't starting. On MSFS 2024 this usually means the SimVar subscription is failing — typically because MSFS hasn't finished booting its internal SimConnect server yet. Wait for MSFS to reach the main menu (not just the intro screen) and try again.

X-Plane detected but no data flows

If the Sim chip reads “X-Plane” but no telemetry arrives, a firewall is usually eating our UDP packets. Try:

• Disable the firewall temporarily to confirm.
• Whitelist UDP 49000 outbound on the bridge process.

Crash on launch

Next-launch recovery flow: if the previous launch crashed, the bridge shows a crash-report dialog on the next start, with the stack trace and a Send via feedback form button. Click it; the form pre-populates with the crash log.

If the app crashes before the dialog appears, you'll need the crash log file directly:

• Windows %LOCALAPPDATA%\ffb-bridge\crashes\
• Linux ~/.local/share/ffb-bridge/crashes/

Attach the most recent .log file to a feedback report.

“Bridge can't keep up” warnings

Diagnostics warns when the control loop rate dips. Causes we've seen:

• Another process on the same core is bursting CPU — a browser tab, a compile.
• On Linux, a cpufreq governor is clocking down the CPU. Switch to performance or schedutil.
• Running in a virtualised environment that isn't giving the guest reliable 20 ms time slices.

Multiple FFB2 sticks plugged in

First-found wins — the bridge grabs the first matching VID/PID and drives that. A UI to disambiguate is on the list; for now, physically disconnect all but the one you want.

Still stuck?

Export a support bundle from Diagnostics and open a feedback report. The bundle contains the session log, crash log (if any), Doctor output, and system info — it's exactly what we need to reproduce without shipping you test builds.