MSFS not automatically loading an external executable on startup if it is designed as Run As Administrator

[MSFS 2024] Bug Reports
,
1

MSFS not automatically loading an external executable on startup if it is designed as Run As Administrator

Version: 1.5.26.0

Frequency: Consistently

Severity: High

Marketplace package name: N/A

Context: TDS GTNXi Pro for MSFS or any other application which has an external executable being auto started by MSFS using EXE.xml

Similar MSFS 2020 issue: Yes

Bug description: Any external executable started by MSFS, via the EXE.xml, but designed as Run Ad Administrator will not be loaded by MSFS on startup. This has happened since MSFS 2020 and occurs in MSFS 2024 as well. While we do not require or set the Run as Administrator option, for some reasons some users have this option checked, hence why automatically loading of exe.XML files fails. At the end of the message is a sample code of the exe.XML file entry. This does not have to do with SimConnect, as we never get that far.

Repro steps: Create an external executable, set up the appropriate EXE.xml section, confirm that MSFS loads the executable on startup. Close MSFS, then right click on the external executable, select Properties/Compatibility tab, check Run as Adminsitrator, then start MSFS and confirm that MSFS does not load the executable, nor does it display an error message that the executable has not been loaded.

Attachments: N/A

Private attachments: N/A

    <Launch.Addon>
        <Disabled>False</Disabled>
        <ManualLoad>False</ManualLoad>
        <Name>TDS Sim Software GTNXi Gauge Integration</Name>
        <Path>C:\ProgramData\TDS\GTNXi\FlightSimEXE\TDSGTNXiFlightSimEXE.exe</Path>
        <CommandLine>-FSIntegration</CommandLine>
        <NewConsole>True</NewConsole>
    </Launch.Addon>
2

Hello @tiberiu11

I think this falls outside of our scope.
This is the expected behavior, a parent process that does not have admin rights cannot start a child process that requires them.
In such case, SimConnect log prints an error with the standard 0x000002E4 ERROR_ELEVATION_REQUIRED Win32 error code.

This should no longer occur if Flight Simulator itself is started in administrator mode.

Regards,
Sylvain

1 Like
3

As a user, I’d be very concerned if a flightsim addon needs root privileges.

4

Hello,

Thank you for the information. While it is great that there is a log error provided by SimConnect, unfortunately this does not help us much if our executable has not been started, hence why I am asking if there is any consideration for a different kind of error message to provide some feedback to users that there is a startup issue?

At TDS Sim Software we do not require admin privileges for the TDS GTNXi to run. Based on the bug reports that we have received, through some unknown means, the “Run as Administrator” checkbox has been checked, which is the root cause of this issue.

1 Like
5

Good to know! I have been using it for some years and didn’t have any such issue so far.

6

We also have the same issue with customers who feel they need to somehow make sure they check that box on their own.

What would you think is appropriate for the simulator process to do? Where would it log this so it’s more apparent? Would you want the sim to pop up a message saying “can’t execute this add-on”? I am not sure what more it can do to be honest…

7

Tiberiu ( @tiberiu11 ),

IMO, it is concerning to me that there are users of your GTNXI that run the standalone bridge application with admin privileges but do not run the sim the same way, so it actually is pretty consistent with what Sylvain ( @FlyingRaccoon ) explained above (i.e., the ERROR_ELEVATION_REQUIRED Win32 error code due to the attempt of a parent process [the sim, in this case] to launch a child process [your standalone client] with admin privileges, knowing that the parent process was launched with basic privileges).

The only ways are to run both the sim and the standalone client as administrator, or both with basic privileges, OR… fully disabling the User Account Control feature on Windows, and forcing both processes to be launched with admin privileges as a result. Good to know though that your client application does not require admin privileges to do the required gauge communication :slightly_smiling_face:

Regards,
Carlos Daniel González Gómez
CEO & Lead Developer - NextGen Simulations

8

We have determined that some users do not know why they check off random boxes for our executable, so we find this odd as well. Such users do not know the difference of running a program in admin mode or not, so it is a mistaken.
We are unable to determine how many users behave like this, but most likely we are only talking of 20-30 users.

9

Those 20-30 users are the loudest, usually. They scream and shout that things are broken, they want refunds, etc.

When you point out what they’ve done wrong, they usually keep defending themselves or claim ignorance.

I often wonder how we could protect our logic from them but… you can’t fight stupid.