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 Diagnostics.
2. Click Export support bundle (top-right).
3. After a short delay, a banner shows the filename and size, with Reveal and Open feedback form buttons.
4. Click Open feedback form — the feedback page opens with your bundle pre-attached.

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 — “windows” or “linux”.
• os-version — kernel version or Windows build string.
• 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 page 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.

doctor.json

Most-recent Doctor-page scan in machine-readable form. Each row carries the check name, status (pass / warn / fail / n/a), and the raw detail string. This lets us see your Doctor state without you having to paste screenshots.

tunables.yaml

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.

simconnect-config.xml

MSFS's SimConnect.xml if the bridge could read one, with any <Password> entries stripped. Absent if you were on X-Plane or Mock at export time.

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.
• Doctor 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.