Documentation in beta. Some text and images will be reworked as the app settles into 1.0. If a section reads stale, flag it via the feedback form.

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?

The cockpit ARM gauge in the top strip must read ARMED (amber gradient). If it reads DISARMED (grey glyph, warm border), click it and confirm. If it reads FAULTED (red), see "Stick was working, suddenly stopped" below — a prerequisite has just dropped.

Is the device detected?

The DEVICE lamp in the top strip should be green ("Ready"). If it's red ("Disconnected"):

  • 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 lamp in the top strip should be green ("Sim connected"). 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 built-in starter closest to your aircraft: Cessna 172 Skyhawk (G1000), Daher TBM 930, Beechcraft King Air 350i, Airbus A320neo, or Boeing 747-8 Intercontinental. Most “wrong” feels come from a profile that was tuned for a different aircraft class.
  • Check the Dashboard's stick-activity panel. It separates the baseline spring from dynamic channels like axis load, engine rumble, ground roll, turbulence, and mechanical one-shots. If effects you did not expect show as active, the sim is reporting telemetry that is driving them.
  • 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 lamp went green briefly and then dropped back to "no sim running" without telemetry actually flowing, a firewall is usually eating our UDP packets. Try:

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

Windows Crash shortly after arming or takeoff

Pre-beta.10 issue. Earlier Windows hardware-mode builds created a large retained DirectInput effect table — one physical effect for each logical simulator cue. On some Sidewinder FFB2 / Windows pid.dll stacks, that call pattern could crash during active flight, often around CreateEffect, SetPeriodic, or native ACCESS_VIOLATION breadcrumbs. This is not an MSFS issue and not a sign that your stick's firmware is bad.

Windows Forces disappear after MSFS pause or a long stutter

Beta.11 specifically targets this class of bug. MSFS pause and Active Pause now suppress dynamic effects immediately, while the stick holds a neutral default spring. On resume, DirectInput spring parameters are reuploaded before effects replay so pitch and roll centring both recover.

If roll force still feels absent after resuming on beta.11 or later, export a support bundle immediately after reproducing it and describe whether the Dashboard showed axis load, baseline spring, or dynamic channels at the time. That tells us whether the pipeline went quiet or the device driver lost an axis.

Beta.10 fixes the architecture: hardware mode now uses one vector constant, one two-axis spring, and a small lazy periodic pool instead of a large retained table. If you're still seeing this on beta.10 or later, open Doctor → Hardware compatibility, run Test hardware effects, then switch to Software-blended periodics if the test fails or the bridge offers that recovery on next launch. Please also send a support bundle so we can characterise the remaining driver stack.

Effects keep playing for ~30 seconds after quit

Pre-beta.9 issue. On Win11 + the FFB2 driver, the bridge's per-effect cleanup on quit was, on this stack, blocking each call for the effect's full firmware playback duration — so in-flight rumble or buffet effects ran out their natural ~32 second timer after the bridge closed, leaving the stick audibly active on the desktop with no app driving it. Fixed in beta.9 — the shutdown path now skips per-effect work entirely and uses two device-level commands (halt-all + reset firmware effect table) that return immediately. Same fix applies on a native crash via the Vectored Exception Handler. If you're seeing this on beta.9 or later, please file a feedback report.

Windows Crash on quit citing 0x80131506

Pre-beta.9 issue. On a fraction of installs, the bridge would crash with a Windows Error Reporting popup citing coreclr.dll and exception code 0x80131506 the moment you clicked Quit or closed the window. Root cause: the UI thread and the runtime's control loop were both calling into DirectInput at the same time on shutdown, and the COM marshaller eventually noticed and tore the process down. Fixed in beta.9 — all DirectInput access now serialises through a single lock at the device boundary so the two threads can never race the marshaller. If you're seeing a 0x80131506 on quit on beta.9 or later, please file a feedback report.

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.

Previous Tuning guide Next Support bundles