Reset XPDR

FYI for anyone wondering the outcome, it was Steam being unknowingly run as Admin, with MSFS inheriting that same privilege level, that was blocking AutoFPS being able to attach to the MSFS executable. All resolved now.

Before you do anything too drastic, send me via PM the contents of one of your app logs, located in %appdata%\MSFS_AutoFPS\log, and I will see if I can tell what is going on.

Did you try everything the readme suggests to try? If after installing and running the app your simconnect always stays red, your TLOD and OLOD values show as zero or you see "Critical Exception occurred: MSFS_AutoFPS - Unable to load DLL 'GpuzShMem.x64.dll' or one of its dependencies" in the log file: Try reinstalling the app with the Repair option selected, then reboot. If any of the redistributables fail to install during this process, try downloading and installing/repairing (as applicable): A Microsoft official version of “Microsoft Visual C++ 2015 - 2022 Redistributable”, which may be missing from your Windows installation. Try installing this and this. The NET desktop runtime from here if still available. Alternatively, go to the Micrsoft .NET 8.0 download page here and download and install the latest .NET Desktop Runtime X64 version. If still not resolved and the error code in your AutoFPS log file is Exception 31, you most likely have a corrupt MSFS WASM installation. First, try deleting the MSFS WASM folder, located under the Microsoft Flight Simulator directory in either %appdata% or %localappdata% for Steam and MS Store install directories respectively, which will rebuild when you next run MSFS. Rebooting is also recommended. If that doesn't fix it, a full clean reinstall of MSFS will be required per the explicit instructions in the FAQ entry here.

Nothing has changed in recent app versions re auto detecting a fixed FPS in Auto Target FPS mode. In this mode, the app will switch to AFixedFPS if recent FPS history is within a very tight tolerance (FPS must stay within ±1%, and the jitter must be extremely small: only 0.25%.) of the dominant FPS detected, but will only stay that way if it is detected that way 5 times in a row. Your experience is basically saying that at least the first assessment meet this criteria but then doesn't after that. This can happen with no fixed FPS set but the view stays constant meaning the FPS is not varying much anyway. Unfortunately, there is no way to tell the difference from a detection point of view, other than confirming that it does the same 4 more times as the app already does. Edit: Just to demonstrate what it takes to get a permanent auto fixed FPS with a real fixed FPS, here's what a run of 5 detections would need to look like: 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8, 39.5, 39.8, 39.8, 39.8, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:57:42.759 [INF] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detected at 40 FPS (override applied) 2026-08-03 08:57:42.759 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 1/5: confirmed consistent at 40 FPS 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.7, 39.8, 39.8, 39.7 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:58:03.051 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 2/5: confirmed consistent at 40 FPS 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.8, 39.8, 39.7, 39.8, 39.7, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.7, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:58:23.343 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 3/5: confirmed consistent at 40 FPS 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.7, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:58:43.651 [DBG] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS detection 4/5: confirmed consistent at 40 FPS 2026-08-03 08:59:03.933 [DBG] [ LODController:DetectFixedFPS ] RawFPS: 39.7, 39.8, 39.8, 39.6, 39.8, 39.6, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8, 39.7, 39.8, 39.8 2026-08-03 08:59:03.933 [DBG] [ LODController:DetectFixedFPS ] Atmpt:1 DomFPS:40 Tol:±0.50 SD+:0.000 SDMax:0.125 In:20 Out+:0 FixedFPS:Y 2026-08-03 08:59:03.933 [DBG] [ LODController:DetectFixedFPS ] Fixed FPS detected at 40 FPS 2026-08-03 08:59:03.933 [INF] [ LODController:DetectFixedFPS ] Auto Target Fixed FPS confirmed stable after 5 identical detections.

Further to this, the first 0.5.3.0 test build has been released which automatically enforces MSFS as the FPS source, regardless of whether RTSS is running or not. Also, DynFG now shows on the app status line in lieu of Man FG that was previously shown:

@kevinfirth , as promised, the first 0.5.3.0 test build is now released and reinstates the spike detection/protection. Note you must have RTSS running, spike protection enabled AND Log+ enabled for this stack panel to show:

No popped out displays on mine. It used to CTD in the past when I had RTSS running, but even with that turned off it still CTDs. Apart from testing with my app on the rare occasions it doesn't cause an MSFS CTD, I rarely use FG of any form as I mainly fly in VR where it is not applicable anyway, so no big deal.

I will do that, since I have made it so that the spike protection checkbox only ever appears if you have RTSS running anyway and could do the same for the hide-able stack panel upon which it would live, so users not using RTSS would not see it anyway. It will make it reappear in the first 0.4.3.0 test build.

@xsever , unfortunately MSFS CTDs as soon as I enable any form of FG with the Nexus mod running, so I am currently unable to assess this. Nonetheless, the underlying principle of using an NFR base for DynFG-related Target and displayed FPS in MSFS_AutoFPS should be sound as that is the lowest common denominator of any form of FG. Let me know what you discover with Nexus mod settings relating to this feature.

That would be helpful. I have the mod, but just haven't used it as I am quite happy with plain old FSR3 2X. I will give it a go now to see what I find too.

Per the readme excerpt I posted a few posts ago, when using DynFG, everything in the app is in NFR-speak so your target FPS should have been set to 29 FPS (Actually, if you are using a true Fixed 30 FPS cap, then you should be using Fixed and the target set to 30 per my last post). Regardless, the mod you are using could be the one capping your FPS to 30 if that is what you have set for its target in the mod, which would explain the 15 FPS NFR the app is showing. I believe that with the mod you should be setting your desired post-FG FPS ie 60, not the NFR FPS AutoFPS requires, so I suggest you try that. I know that it can be a bit confusing with all this NFR and post-FG speak, but the general rule is as follows: MSFS Settings - all NFR-speak. MSFS_AutoFPS - all post-FG speak, EXCEPT DynSet which is NFR-speak. Dynamic/Adaptive FG driver/mod settings - target FPS post-FG speak.

Yes it was removed from the UI as I received no feedback during the test program that anyone had tried changing that value so IMO it was not worth it taking up UI real estate. It can still be changed in the common config file per the readme description of this new feature:

I'll revise my advice to say that it depends on whether your FPS cap of 36 is a Fixed or NTE FPS, as defined in the readme FAQ as follows: If your FPS cap of 36 is Fixed, as defined above, then use Fixed Target Man 4X FG and try a target value of 136 (based on what you say the Nexus mod caps it to, not its real 144 potential). If your FPS cap of 36 is NTE, as defined above, then use Manual Target Man 4X FG and try a target value at least 5% below 136. 128, as you have suggested, should be fine. If you are still struggling with what to set, PM me the contents of the log file, located in %appdata%\MSFS_AutoFPS, of your best attempt and I will take a look.

The readme FAQ covers this as follows: ie. Select this: then this:

Alrighty then. It's a new day so I'll have another go at answering the queries from yesterday. Firstly: There were no functional changes to auto-start functionality in the app installer in 0.5.2.0 (in fact since Feb this year), so it should still be working. Just run the installer, select MSFS as the auto-start option, make sure MSFS 2024 is checked then click update. You should then see the following: To confirm it has been added correctly, open your MSFS 2024 Exe.xml file in notepad and look for an MSFS_AutoFPS auto-start entry: Start MSFS 2024 and it the app should auto-start about halfway through the loading process. If this still isn't working, please tell me specifically where in these instructions it occurs.