Hello, I am using Axis and Ohs v4.56 build 19 with MSFS 2020, on a system with an RTX 5080 GPU (driver 591.86). I have identified a fully reproducible crash pattern: - With AAO active (only 2 throttle axes assigned, for HondaJet HA-420 FADEC): MSFS crashes within a few minutes with Windows Event ID 153 nvlddmkm. - With AAO completely closed, same flight, same aircraft, same route: zero crashes over multiple complete flights. Additional observation: AAO adds approximately +1.5ms to CPU render time when active. This disappears when AAO is closed. This strongly suggests AAO triggers a GPU driver timeout (TDR) through its SimConnect interaction, possibly specific to the RTX 5000 series. Could this be investigated for a future build? Thank you.

AAO does not do any graphics related calculations. If anything, it is the .Net WPF framework that the app is running on that could cause it (=Windows itself) . If that is the case, then AAO will not be the only app where this can happen.

But. In 6 years you have been the first and only person of a low 5 figure total number of users to report this. IMO that would suggest that this particular behavior is specific to your computer.

Please note that AAO should always be run minimized (there is a feature to do this automatically in the Application menu). When nothing is rendered, there shouldn't be any problems - right (?? I don't really know, just guessing).

Edited May 15May 15 by Lorby_SI

Here is another idea, which is a bit more esoteric: maybe this is about the axis that you've assigned? Maybe by choosing just the right (in this case wrong) event, some animation in the model gets "overloaded" somehow (too many frame changes, animation position out of range?) and causes the delay and the crash? Did you try this with other axis - or even just a single button? What about different aircraft?

Edited May 15May 15 by Lorby_SI

Hello Oliver,

Thank you for your quick and detailed response.

First, I will test with AAO minimized during flight.
I was not doing this before, so the throttle cursors 
were updating continuously in the WPF window during 
the entire flight - which could well explain the issue.

Regarding axis assignments: I am currently using 
THROTTLE1_SET and THROTTLE2_SET (Percent, no AXIS variant).

I realize this might be a second cause: sending discrete 
events continuously (at every micro-movement of the 
physical throttle lever, including vibrations) could 
saturate the MSFS main thread, which is already handling 
physics, avionics, SimConnect and 3D rendering 
simultaneously. Multiplied by 2 throttles, this could 
cause a SimConnect overflow leading to a GPU timeout 
and the nvlddmkm 153 crash.

I will test in this order:
1. AAO minimized, same assignments (THROTTLE1/2_SET)
2. AAO minimized, switching to THROTTLE1/2_AXIS_SET
3. Single throttle only if needed

I will report back with results.

Thank you again for your involvement.

AAO minimized: still crashes. Switched to THROTTLE1/2_AXIS_SET but throttle levers are now inactive in cockpit - probably a value range issue (0-100 vs -16383/+16383)? How should AXIS_SET be configured in AAO? My settings are now :
L:THROTTLE1_AXIS_SET, percent. Axis min 0 axis max 100. could you give me the good settongs ?
Thanks in advance.

2 hours ago, Cutterwood said:

AAO minimized: still crashes. Switched to THROTTLE1/2_AXIS_SET but throttle levers are now inactive in cockpit - probably a value range issue (0-100 vs -16383/+16383)? How should AXIS_SET be configured in AAO? My settings are now :
L:THROTTLE1_AXIS_SET, percent. Axis min 0 axis max 100. could you give me the good settongs ?
Thanks in advance.

There is no general rule of "how" this is done. These things are potentially different for every single aircraft - they depend on what the aircraft developer has implemented.

With the HJET, none of the default events works for me. I had to implement special scripts to control the thrust levers. The HJET developer made it impossible to use defaults, instead one must operate the animation LVar in a certain way.
I'm not sure how I can explain this, so here is a template of my aircraft configuration. But was made for the Honeycomb bravo and a simple Thrustmaster joystick.

https://www.dropbox.com/scl/fi/bzmcqy22x2jgm4wlc54qm/HJET.tmpl?rlkey=hpuwjdxkbp7tymlkene4yweod&dl=0

Btw. Events never have a unit, there is no "number" or "percent" or anything with events. Something starting with "L:" is not an event, that's a variable. Those do have units, but they work very differently from events.

On a side note, I have the exact same driver version that you have, albeit with an old GTX 3090. I never had a single crash with it.

I imported your HJET template (axes only, cancelled the button assignments as I don't have a Honeycomb Bravo). Same crash in under 2 minutes. The assignments look identical to what I had before, except for the curve shape 1.2. At this point I believe the issue is not in the configuration itself, but in AAO running alongside MSFS on an RTX 5080 (Blackwell architecture). Can you give me your opinion.

I imported your HJET template (axes only, cancelled the button assignments as I don't have a Honeycomb Bravo). Same crash in under 2 minutes. The assignments look identical to what I had before, except for the curve shape 1.2. At this point I believe the issue is not in the configuration itself, but in AAO running alongside MSFS on an RTX 5080 (Blackwell architecture). Can you give me your opinion.

Opinion? Can't say that I have one. This makes no sense - at all. This problem is currently limited to your computer, which makes it impossible to reference anything. Update the graphics drivers, make sure that your .Net libraries are current, update the operating system. If there is a problem, it is likely that someone else caught it in another game/WPF app (TMBK the sim itself is one too), and that NVidia or Microsoft have corrected it by now.

You could switch off the graphics on the AAO main dialog using the three little icons above the button and axis lists. But if you even have trouble when the app is minimized, that is probably futile as well. Make sure that no other addons are running in parallel, especially not those that essentially do the same thing (SPAD, FSUIPC, MobiFlight).

Disable the AAO "lorbysi-content-*" package(s) in the Community folder, just to see what happens (=rename the manifest.json to manifest.off)

Personally, I never had much luck with MSFS 2020. I cannot fly from any airport south of EDDF, the sim will immediately crash. If it loads at all, in most cases it gets stuck between world map and the simulation. I cannot fly for more than 30 minutes, because the sim will (of course) crash on me at around that time. All this has been happening for years now, on two different computers at that (but both development machines with many libraries and odd memory layouts). And this happens with or without AAO running.

We are currently using 5080s together with AAO and lots of AAO specialities (like gauges) in a commercial (=hardware) sim that is running P3D V4 - zero issues. So it is not about the card, that much seems certain.

Edited May 16May 16 by Lorby_SI

Thank you for this honnest answer. I must be lucky as with TBM 930 and Hondajet (without AOA and therefore without Fadec), I can fly everywhere in MSFS 2020.

I must thank you for the link to your own template. Yesterday I made a mistake using "import template" instead of "apply the template to this aircraft". Now I can see your assignations. I clean all of them i don't need and keeps only the two throttle axis assignments. And I can see a real improvement. 3 flights completed this morning without crash using your assignations. Some macro-stuttering over dense areas (Paris), or taxiing at LFLL) but no crash. Thank you very much for your precious help.

Edited May 17May 17 by Ray Proudfoot
Own quote removed.

New question to Lorby_SI. :
Still no CTD but experiencing 1-second GPU drops (5-8% GPU usage only) with frozen image, 4-5 times per flight, no CPU spikes at the same time.. Two occurrences 15 seconds apart during ILS approach at 1500ft, AP+AT active, no physical input. Could the RPN script polling rate cause periodic SimConnect interruptions?

Could the RPN script polling rate cause periodic SimConnect interruptions?

There is no such thing as a "RPN script polling rate". AAO processes the scripts, not the simulator. The app has its own RPN parser. Only atomic variable values are synchronized with the sim. AAO constantly adjusts the refresh rate to the actual capabilities of the sim, by measuring the return times. You can only increase the refresh rate by hand, by settings axis to update "continuously" instead of "On change" and by activating "joystick high sensitivity" in the hardware menu. If you didn't do this, AAO will "turn" at about 18 Hz, dynamically adjusted to the actual load situation.

Make sure that "MSFS SU12 LVar processing" is ON in the Application menu.

If you suspect a SimConnect flood, I suggest that you take a look at the AAO logfiles. But you would have to somehow force that flood to happen, AAO won't do that on its own in normal operations. More likely, stutters are caused by the sim processing errors internally. Those you could check using the console in MSFS developer mode.

But since this is only happening on your computer, there is no frame of reference for me to give advice. To me this sounds like a general instability and that AAO is simply pushing the sim over the top. I don't even think that it is GPU related either - that you got an NVidia error was just coincidence IMO (=an exception bubbling up and ultimately being thrown by the most active component of the sim?)

Edited May 19May 19 by Lorby_SI

HI,
All 3 settings in AAO were on line with those in your answer.
I looked at log files (*.txt.). There are 2 or 3 files per MSFS session : same number as strong stutterings. Each of these files have the same single line :
"MW: Exception received: 3 from send id 164 errloc 164".
Is this a known SimConnect error code?

HI,
All 3 settings in AAO were on line with those in your answer.
I looked at log files (*.txt.). There are 2 or 3 files per MSFS session : same number as strong stutterings. Each of these files have the same single line :
"MW: Exception received: 3 from send id 164 errloc 164".
Is this a known SimConnect error code?

The number of log messages is irrelevant. Only the timestamp is, that is what must coincide with your stutters.

"3" is an unknown ID (of an event, variable, etc.). Some of those will always be there in the logfile because AAO forces that exception when it connects to the sim to get a baseline for future error reports (SimConnect doesn't tell you why something happens or when exactly, just "oops, something went wrong"). In general they are nothing serious, and nothing that should happen during the flight. If they happen during that flight, that would mean that AAO had to disconnect for some reason and has reconnected automatically. You would see that in the StartupLog. Just be mindful that the timing of the events is the important part, not their mere existence.

In all other cases a "3" would mean that you are using a variable or event that the sim doesn't know. But then it won't just be a handful of exceptions - if you really assign an incorrect event to an axis, you will see hundreds of them.

It is next to impossible to troubleshoot this. The simulator has too many moving parts, and apart from all the Javascript in play, there can be additional SimConnect clients in the aircraft logic that you don't even see. I suspect that at some point several things go wrong at the same time, and the sim stutters. Trying to find a singular cause for that is - challenging. Did you disable the lorbysi - Packages in your Community folder?

All 3 settings in AAO were on line with those in your answer.

What does that mean? What they should be is

• Axis to "On Change"

• Joystick high sensitivity: OFF

• MSFS SU12 LVar processing: ON