Update with new observations and logs
The airport search in the EFB is still one way to trigger it. I now have logs from a normal flight on 11 October (Fenix A321, MSFS 2024 1.8.16.0) that show what these shutdowns have in common. Both engines shut down three times, and each time it happened in the same second in which MSFS released its input block after a sim UI window (the Microsoft EFB) had focus:
1) Taxi, 10:04:55 local: Microsoft EFB open to read the taxi checklist, no search.
2) Descent, 10:37:18: Fenix app inside the Microsoft EFB, Landing Distance page.
3) Descent, 10:41:32: sim UI window open again.
Three independent logs agree on the timing: the aircraft's system log, FSUIPC L:var logging (both engine master variables go to 0 together) and a camera add-on that logs when MSFS blocks and releases the sim inputs. All physical switches, including both engine masters, stayed ON. No key press was logged at those moments.
So the search is one way to get into this situation, but the moment that matters seems to be when MSFS hands control back after the EFB. That also fits the A346 Pro case: there the trigger was the airport search in the Microsoft EFB as well.
Question to Aerosoft/ToLiss: could you check whether the A346 Pro reacts the same way when the Microsoft EFB is opened and closed with engines running? Your aircraft logs might show where the engine master change comes from.
Details and the full timeline are in my updated MSFS DevSupport report:
MSFS DevSupport
Native EFB bug (FOCUS_INPUT_FIELD / UNFOCUS_INPUT_FIELD)...
261011_logs-excerpt.pdf (57.7 KB) Update: three dual engine shutdowns in one normal flight, each at the moment MSFS releases the sim UI input block A new data point that refines my original report.Thanks!
261011_logs-excerpt.pdf
By
micromoon ·
![Rafi [Aerosoft]](https://forum.aerosoft.com/uploads/monthly_2026_02/Rafi.thumb.jpeg.4a2295ac3b06910d02314bef45e636ec.jpeg)
