Current release. FFB-Bridge v1.1.2 is live. These docs track the current app described by the release manifest. If a section reads stale, flag it via the feedback form.

Troubleshooting

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

Windows 11 SmartScreen or Smart App Control stops launch

The Windows installer is code-signed by the Rohsam publisher identity, but brand-new signed files may still have low SmartScreen or Smart App Control reputation. If Windows shows a warning, verify that the file came from ffb-bridge.com, check the published hash when available, and confirm the publisher is Rohsam Inc. or RohsamInc.

SmartScreen prompts can usually be expanded with More info after you have verified the publisher. Smart App Control may be stricter on some Windows 11 systems and may block a new build until its reputation improves. Microsoft's own guidance:

Microsoft: Smart App Control frequently asked questions

If you see an antivirus quarantine rather than a Windows reputation prompt, email the flagged sample details to supportffb-bridge.com so we can investigate.

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 matches a supported device: 045E:001B, 046D:C287, 046D:C286, or 046D:C283.
  • Linux on the Support page's Health checks tab, the 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 Sim 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 control-system feel at the top of the Tuning page's Stick feel group. A heavy jet set to Manual, or a light GA aircraft set to Fly-by-wire, will feel wrong even with otherwise good gains — match it to the aircraft (Manual, Hydraulic-boosted, or Fly-by-wire).
  • 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.

Health check 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

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

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

If roll force still feels absent after resuming on a current build, 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.

The current architecture uses one vector constant, one two-axis spring, and a small lazy periodic pool instead of a large retained table. Version 1.0 also resets the raw HID/PID effect table before arming after simulator disconnects. If you're still seeing this on a current build, open Settings → Hardware, 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

Earlier Win11 + FFB2-driver issue. 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. Current builds skip per-effect work entirely on shutdown and use 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 a current build, please file a feedback report.

Windows Crash on quit citing 0x80131506

Earlier 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. Current builds make 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 a current build, 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

The Diagnostics tab 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 supported sticks plugged in

When more than one supported stick is attached, a device picker lets you choose which one the bridge drives, and the choice is remembered across restarts. Reopen it from Settings → Hardware → Force-feedback device → Change device…. Changing the chosen device is restart-required.

My force-feedback stick isn't one of the four supported ones

The four validated sticks (SideWinder Force Feedback 2, 045E:001B; Logitech G940, 046D:C287; Force 3D Pro, 046D:C286; WingMan Force 3D, 046D:C283) are plug-and-play. To try another force-feedback joystick, turn on Settings → Hardware → Allow unlisted devices (experimental). The bridge then drives an eligible joystick with safe defaults; use the live invert and pitch/roll swap calibration on the same tab to fix direction, and crash-recovery is there as a safety net. Wheels, gamepads, and single-axis devices can't be driven as flight sticks — they're routed to the FFB Probe at ffb-probe.com instead.

Still stuck?

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

Previous Tuning guide Next Support bundles