Handle leak when having LNM open but no simulator running

[tomatosalat0]

Hi,

first of all, thank you for this lovely tool - I really like it a lot. But: I've noticed that LNM has a handle leak.

Environment:

• OS: Windows 10 64 bit
• Installed Sims: P3D + MSFS + X-Plane
• Installed SimConnect Client versions:
  • Microsoft ESP SimConnect Client v1.0.20.0
  • Microsoft Flight Simulator SimConnect Client v10.0.60905.0
  • Microsoft Flight Simulator SimConnect Client v10.0.61242.0
  • Microsoft Flight Simulator SimConnect Client v10.0.61259.0

Steps to reproduce:

• Start LNM but don't start any Simulator
• Have the Connect automatically option checked
• Open the Task-Manager, open the Details tab and include the Column Handles
• Search for the littlenavmap.exe entry and look at the Handles count - it will increase about every ~5 seconds. The number will continuously grow.

Observations:

• If the Connect automatically option is unchecked, the handle count won't increase anymore.
• After starting MSFS while keeping LNM open, the handle increase will stop as soon as a connection to the sim is established.
• After closing the sim while keeping LNM open, the handle counter will start to increase again.

I hope you can reproduce the issue with the steps mentioned above.

[albar965]

Thank you for the detailed report! Very good.

I can reproduce this with increasing number of handles in the Task Manager. Unfortunately I do not see anything in the Resource Monitor which could also tell me what handles are left.

I have to dig into the SimConnect code and check if something is not closed there.

[tomatosalat0]

Great to hear that it is not only on my side.

I just tried to find out which kind of handle is leaking and it seems like its an Event handle leak (probably created by CreateEventA, CreateEventW or CreateEventEx). Unfortunately the handle itself doesn't have a name (or at least the tool I used didn't show any).

I only know about htrace to track the creation call stack of every handle, but I don't have the Driver SDK installed on my machine to check for that by myself right now.

I would probably need a lot of time to get into LNM source code, so I can't give you any more detailed hint right now.

[albar965]

This is a SimConnect issue. Handles get lost as soon as I call SC_Open. Calling SC_Close in case of failure makes no sense since the resulting handle is NULL anyway.

No other parts of LNM cause this. No handles leaked as soon as I comment in SC_Open.

No idea how to fix this. Using latest MSFS SimConnect requires a 64 bit build. 32 bit build is kept to have FSX support.

[albar965]

No idea how to work around this. Maybe unload and reload the whole DLL.

[tomatosalat0]

Unloading the DLL won't fix the issue. Handles are bound to the process in Windows afaik - so a process restart is the only option to unload the handles.

I just thought about it as well and got four ideas for a work-around (and do be honest, all of them are quite ugly in my opinion):

• Creating a separate executable which only has one purpose: check if a sim-connect connection can be made. When the executable starts, it simply tries to open a SimConnect-connection, closes it if possible and returns if it was possible or not (e.g. by using the process exit code). In LNM, you periodically run this executable while no connection is alive and only attempt to open a SimConnect-connection if the executable indicated that it is available.

• Create hooks into the methods CreateEventA, CreateEventW, CreateEventEx and CloseHandle within your process before attempting to start a SimConnect connection. Within the hooks, you keep track of all handles which where created and not closed while executing your SimConnectApi::Open method. After you're done with the SimConnectApi::Open method, release the hooks and do a cleanup if the creation of the SimConnect connection had failed. (edit: not that this method gets more complicated when having multiple threads running, so you need to check GetCurrentThreadId to make sure that you don't close stuff other threads within your process have created)

• Default your AutoConnect option to false in the UI with a notice that a SimConnect-library issue will cause a memory leak if no sim is running.

• Add an FSUIPC connection-check method (optional). So only attempt to open a SimConnect-connection if you could connect to FSUIPC first. I've used FSUIPC in the past (but not with MSFS) and didn't have an issue with it when no sim was running.

Those are the options which just came to my mind. Don't know if you really want to implement any of those though.

[albar965]

Thank you for the hints. Very helpful.

Creating a separate executable ...

Overhead. Another program to maintain and build.

Create hooks into the methods ...

Sounds tempting but also dangerous. You never know what you're closing there. BTW: It's not the main thread but there is only one thread dealing with the connection.

Default your AutoConnect option to false ...

Not really but I can stop autoconnect (not disable the option, just stop) after half an hour or so and show a warning dialog. Or resume once LNM is activated, etc. Or increase reconnect time for each unsuccessful attempt.

Add an FSUIPC connection-check method ...

Overhead and support (need to help people installing). I know FSUIPC from FSX but I'd rather not use this path.

The hooks and the warning seem feasible.

Again thanks for the help. I'll see what can be done.

Alex

[albar965]

Postponing since workaround 2629de452118862dc9f2881fc84abf6652676563 mitigates the issue.