FSX Gauge doesn't unload...


I am running into a problem that is driving me crazy... After so many years in FS development, I never saw this.
I was fixing a small bug in my Airbus Series that I now use with FSX. The series is compsed of 7 aircraft (A318, A319CFM, A319IAE, A320CFM, A320IAE, A321CFM and A321IAE). With the bug fixed, I recompiled all the aircraft, and had a problem with only 1 of them: the A319IAE. They all share approx 95% of the code, so this was surprising.
But more surprising was when I tried to understand why, doing some changes in the code, I couldn't regenerate the gauge DLL as if the A319IAE was still loaded in FSX. What I usually do is load another aircraft, let's say the stock 737, compile and link to generate my aircraft gauges, then load my aircraft again in FSX, which loads all the gauges. I did this, but it didn't work and I had to stop FSX to generate the gauge. My understanding is that the A319IAE gauge is not unloaded as it should when I select the 737 in FSX, it is only unloaded when I quit FSX.

Isn't it strange? It is the first time I see this... Did you see this already?
If someone has an explanation, I would be glad to understand why the gauge is still "held" by FSX when the aircraft is unloaded.
Needless to say, this gauge is used by no other aircraft and it is located in its panel folder.

Thanks for any help,


Resource contributor
If you've hooked the message queue for FS and not unhooked it, the dll with the hook function will not be unloaded.
I will carefully look into this. Nevertheless, the probability is low because this aircraft uses the same code as the 6 other ones regarding that aspect, so I don't understand why it is the only one that fails.


Resource contributor
Eric: if you're using Windows 10, it introduced that particular intermittant bug some updates ago. It frustrated and annoyed me enough that I switched my main development platform to P3D, only running a 32-bit compile when I need to check compatibility with FSX.
I think you are right and this is the reason.
I think this because I noticed the following:
1) when the gauge DLL is loaded in FSX, you can rename it !! I did this for testing only, to see if the DLL was locked or not, and it worked. On Windows 10 you can change the name of a DLL that is being used, but if you try to delete or overwrite it, Windows will not let you do this, fortunately... I am sure this was impossible with Windows 7.
2) I checked my (old) code and it appears the A319IAE uses the EXACT SAME code as the A319CFM, the only difference is made in external configuration files. So there is no logical reason to explain why one works and not the other. I must say this aircraft uses only 1 gauge DLL that contains everything.
I even thought this may come from the aircraft.cfg wrongly configured, but I checked it and it is OK. I wonder if it may come from the model, I don't think so... But I will do additional tests using the same aircraft with another gauge DLL and we will see.

Anyway, if you are right and the reason comes from this Windows 10 "bug", is there something I can do to fix it? Or a workaround?



Resource contributor
Eric: I'm not aware of a workaround, which is why I switched to developing on P3D when I found that platform didn't exhibit the same behaviour. I say 'I found' but the subject came up in another thread (can't find it :() and that was the solution proposed within the thread.

Doug: OUCH!!!! So that's the reason.
Doug, you are a genius !!
Indeed, I found an entry in the registry, whcih name is "D:\Games\Steam\steamapps\common\FSX\fsx.exe" (the location of my FSX SE) and value is "$ IgnoreFreeLibrary<A319IAE_FeelThere.dll>", which is the name of my library that was not unloaded.
I searched everywhere in the FSX config files, cleaned the [Trusted] section of fsx.cfg to no avail, I would never have the idea to search into the registry.

I couldn't find the reason why this entry was created in the registry, but I removed it and everything works fine now.
I don't know how to thank you, this problem was really driving me mad :)