Support bundles

A support bundle is a single ZIP that packages the state of the bridge at the moment something went wrong. It is the one artifact we'll ask for when triaging a ticket. This page describes what's in one, exactly, so you know what you're sending.

How to export one

1. Open FFB-Bridge and navigate to the Support page (sidebar), then the Diagnostics tab.
2. Click Support bundle (top-right of the Diagnostics card).
3. After a short delay, a banner shows the filename and size, with a feedback-form link and, where available, Reveal file.
4. Open the feedback form and attach the ZIP if you want to send it.

What's in the bundle

A bundle is a plain ZIP. The filenames below are the complete allow-list — the bundle will never contain anything outside this set.

sysinfo.txt

System metadata. Plain text, key:value lines. Fields:

• os-name — “Windows”, “Linux”, or “macOS”.
• os-version — kernel version, Windows build string, or macOS version.
• distro — on Linux, /etc/os-release PRETTY_NAME.
• cpu-model, cpu-cores — from /proc/cpuinfo or Win32_Processor.
• ram-total-mb — from /proc/meminfo or Win32_ComputerSystem.
• dotnet-version — runtime version of the bundled .NET.
• platform — explicit key for the Linux-vs-Windows branch.
• locale — current user locale.
• bridge-version, build-hash — bridge version and git SHA at build time.

session.log

Full event log for the current session. Same content as the Diagnostics tab's log strip, but including everything from launch, not just what's visible. UTF-8.

last-crash.log

If the previous launch crashed, the crash log lands here. Stack trace, thread dumps, the final few log lines before the crash. Absent if the session hasn't crashed.

previous-session.log

The rotated log from the run before the current one, when present. After a crash-and-restart report, this is often the file that shows what happened before the restart.

doctor.json

Most-recent Health checks scan from the Support page in machine-readable form. Each row carries the check name, status (pass / info / warn / fail / ready / checking / n/a), and the raw detail string. This lets us see your health-check state without you having to paste screenshots. The file is named doctor.json for historical reasons — the Support page used to be called Doctor.

tunables.json

The active tuning profile's values at the moment of export. Same schema as a saved profile. Used to reproduce the exact force configuration you were flying.

hardware-settings.json

Hardware compatibility settings at the moment of export: software blending, smooth steady forces, axis polarity, pitch/roll swap, raw-HID preference, unlisted-device opt-in, and whether live toggles diverged from persisted settings.

simconnect.txt

MSFS's SimConnect.xml if the bridge could read one, with non-localhost IP addresses redacted. If none was found, this file says so rather than guessing.

Platform extras

Windows bundles include hid-devices.txt for matching Plug and Play device records. Linux bundles include usb.txt, evdev.txt, udev.txt, and dmesg.txt for USB/input stack context. Every bundle also includes README.txt with a contents summary and privacy note.

What's NOT in the bundle

The support bundle builder uses a strict allow-list of filenames. It won't include anything outside that list, even if something matching is present in the same directory. In particular:

• No saved passwords or credentials. The bridge doesn't store any.
• No profile files other than the active one.
• No system logs, journals, or anything outside the bridge's own data directories.
• No network packet captures.
• No cloud tokens (the bridge doesn't use any).

Server-side processing

When you attach a bundle to a feedback report, the site's intake worker parses it to extract useful indexable data into our database:

• System info into a summary row for grouping (“how many reports from this distro?”).
• Warning and error lines from the log, with stable error signatures, so we can see at a glance how many people hit the same bug.
• Health-check results for a breakdown of what's failing across the userbase.
• The verbatim file text of every allow-listed entry, stored so we can re-read context when triaging.

The raw bundle itself is retained for a short window (30 days by default) so we can re-parse if our extraction logic improves. After that, parsed data is kept; the raw blob is dropped.

Limits

In practice a normal bundle is under a megabyte. These limits are there to rule out hostile uploads, not to rule out real reports.

Sending without the feedback form

If you'd rather email the bundle directly, write to feedback·ffb-bridge.com (replace the · with an @) and attach the ZIP. The server-side parser doesn't run for email, so the triage is slower — but the bundle is just as usable.