TREAT INSTALLATION AND RUNTIME AS SEPARATE SYSTEMS
The installer, Fenix application and Microsoft Flight Simulator have different jobs. The current support instructions describe obtaining the installer through the customer dashboard, selecting the product and installing its package; the installer Launch control opens the Fenix application rather than starting MSFS. Establish which component is running before investigating an unpowered aircraft or missing display. A successful installer login or download is not evidence that the runtime connection inside the selected simulator has been established. Begin the first validation flight with the intended platform and aircraft package clearly identified. [136, Getting Started: installation and application launch] [137, Installer versus Fenix application; product installation and Launch]
Fenix instructs users to close both MSFS and the Fenix application before installation. Preserve the installed product/version and review the relevant changelog as part of an update, then perform a known-state check before relying on saved hardware, livery or integration assumptions. The installer and aircraft package need not be the same versioned item. If installation fails, retain the exact stage and message rather than repeatedly changing simulator settings that the installer has not yet used. The support article identifies an installer log that can help distinguish that failure from an in-flight runtime problem. [137, Installation prerequisites, version display and installer-log location]
MSFS 2020 and MSFS 2024 need to remain separate columns in the operational record. Current Fenix livery documentation uses aircraft.cfg and a base container for the former, and livery.cfg tags for the latter. Some equipment options are platform-specific. An apparently identical paint scheme can therefore be delivered through different package and configuration arrangements. Verify what was loaded instead of assuming that a working 2020 livery or hardware profile proves the corresponding 2024 setup. Use the actual product and platform instructions for any package change. [70]
After an update, validate a short representative chain: aircraft activation, settled panel state, expected electrical state, display response, control calibration, a data request and any integration essential to the intended exercise. These are author-proposed verification points drawn from the documented setup tasks; they are not a new aircraft checklist. If something differs, identify which link failed before reinstalling the whole product. A narrow reproducible observation is easier to investigate than a report that an update made every part of the aircraft behave differently. [136, Recommended setup tasks] [61, Panel-state transition] [75, Control calibration]
Keep the setup record alongside the flight's aircraft record. Note platform build, Fenix build, product, livery/options and external providers, with the date of the reference used. Dated release and known-issue notes can then be compared with the actual installation. The 21 October 2026 release and 22 October hotfix are identifiable events in this edition's evidence, not promises that either remains the newest build indefinitely. Apply the same discipline when an official support page describes an older simulator update or a particular device rather than the entire current product. [82, Official V3 release identity] [122, Version 3.0.0.7454 announcement,22 October 2026] [83, Developer issue snapshot,24–25 October 2026]