Issue: Fenix systems or displays suddenly crash or stop responding, while MSFS 2024 itself continues running.
I have contacted Fenix Simulations regarding this issue, and they suggested that it could potentially be related to an error within the latest AIRAC navigation data.
The problem started after updating to the latest Navigraph AIRAC cycle.
Could you please investigate whether there are any known issues with AIRAC 2611 in the Frankfurt area, particularly involving waypoints, airways or navigation data that might cause the Fenix FMGS to crash?
I would also be interested to know whether other Fenix V3 users have reported similar problems since the latest AIRAC update.
Hm,
Thanks for your report - the only thing I can do is compare an older cycle with a new one, but I don´t know if this is helpful. I´m also not sure what Fenix means by “error in the latest cycle”. They have changed the complete version from v2 to v3…
But I will make the comparison to ensure this is not navdata-related…
I have just seen that the database Fenix uses is not the same as the one we offered to Fenix via our API. It seems Fenix is doing something to our original database that makes it impossible for us to identify an issue. I have contacted with Fenix now to look at how we can proceed here.
Hello, eventually I can add some valuable info to this. I did experience this a few time already and it seems always to happen around the Waypoint LOVME at approx FL250-FL270 after departing out of EDDF.
Hi,
Thank you very much for your input. I have checked the waypoint and the surrounding area. The waypoints in the database are defined correctly, as are the airways in this area.
Honestly, I’m not sure the data is the reason for this issue. The Fenix dev is back in a few days, and I hope we get more details about it.
We have no real reference because, with V3, they change the database as part of their own process, so what you see is not 1:1 with what we offer. There is a step between Fenix.
Thanks, but we must wait on Fenix because, as I wrote, they don´t use our database as we offered. What I have seen is that they add some tables and indexes, but I don´t know exactly what else they change.
Also, I´m unsure why data (external one) should create a CTD - even when I love this waypoint … anyway, we must wait; sorry, we can´t do more here at the moment because we also have no reference (older cycle) due to the version change (v2->v3) in the Fenix.
I might help with some additional information here as I can reproduce the exact behavior (it is not a CTD but a crash of the external Fenix app that leads to the behavior seen in the video above).
For me that happens when passing ANEKI all the time. The Fenix crash log shows
11/5/2026 1:22:59 PM System.NullReferenceException: Object reference not set to an instance of an object.
at _jlEE1UbAZPK8dXW7zcXkKBPHpvi._R2GFF2Dvloy109WR3P70qkTDY8P._mC5uNs0jCu7E7iXb8StQp3ZWfuc(Int32 , RadioIDEnum , Boolean& , Double& )
at _jlEE1UbAZPK8dXW7zcXkKBPHpvi._R2GFF2Dvloy109WR3P70qkTDY8P._bbuE6Mxi9UiERexS0Sxtbbxd5Ug(Int32 , RadioIDEnum , Double& )
Although the stack trace is obfuscated, the variable RadioIDEnum might indicate, that there is an issue with a radio frequqeny (which could be radio, NDB, VOR, etc.).
I know that input from the Fenix side is required, but this might help to gather some additional information.
Gentlemen, update on this: it seems this is a bug in Fenix, and they are working to fix it and will push a fix as soon as possible. According to Fenix, this is not navdata-related
I like it
So, please be patient. I´m pretty sure they’re doing their best to solve it ASAP. Anyways, thanks for the input here, even when it has nothing to do with our data. It shows, we are a real community
… anyway, we must wait; sorry, we can´t do more here at the moment because we also have no reference (older cycle) due to the version change (v2->v3) in the Fenix.
