dll troubles

I've created a gauge dll which includes SimConnect client code, Win32 (not MFC) and DirectSound functionality.

It runs fine on both my PCs and most of my testers. However, on a couple of testers' PCs it appears that the dll doesn't load at all, i.e. the gauge faces and switches aren't drawn and no custom programmed functionality is working.

I statically linked the run-time depedencies (compiled under VS 2008) so there shouldn't be any dlls required. (Other SimConnect clients work ok.)

Anyone got any ideas about how I can go about resolving the problem? It's got me baffled.


Hi Folks

Simon -
Only a guess,
sure I'd seen something elswhere along these lines
when investigating the Mission Go To Briefing CTDs.

Could it be that you've missed including a relevant library.

And those users which it doesn't work for
do not have the relevant SxS assembly versions installed
which your statically linked content depends on.

Any differences in their FSX version & service pack levels ?

Also check for -

If the fails are on AMD processors.
ISTR JimK came across something along these lines, (? SSE2 instructions ?).

Permissions on Vista, incase something got dropped ?

Last edited:
They're both running XP SP3 and FSX SP2.

I've stuck a new HD in my desktop today and done a clean Windows XP SP2 and FSX SP1+SP2 installation and absolutely nothing else and my software works fine on it. I didn't need to install any VS libraries, .net or anything.

It's really puzzling. However, it occurs to me that both the folks having problems are likely my only testers running non-English Windows or FSX. I sure hope there's no differences between service packs for different localisations...

Anyone know of any free tools I can get them to use to monitor the dll loading? i.e. to get some kind of log file if dependencies are not found, etc?

It's worth mentioning that FSX is not crashing, so it's nothing in my in-process gauge dll code otherwise it'll kill all of FSX. It's just that the .gau is failing to load. They get asked permission to use it (as it's unsigned) and grant it, so it's not like FSX can't find it either.

Hi Folks

Simon -
Again just guessing :)

Localisations -
Apart from the documentation and GUI
ISTR from forum discussion that -
- some folder names are localized, (simobjects subtree)
- My Documents and subtree is localized

May also be others.

Russian SDK has a different build number.

Might it be a decimal separator issue, (dot v comma).

Not saying the following is the case. :)

Your dll may work on an out of the box installation,
but if they're box has an update applied,
it may then break something.

As per midstream releases of VCRedist, (version 8.0.50727.870 to version 8.0.50727.3078)
broke loading any missions.
See - Missions - Go To Briefing - CTD (FSX/A)

For process monitoring -
there's a wealth of utilities over at - Windows SysInternals
Process Explorer
Process Monitor

As for granted permission
check their relevant lines from their fsx.CFG [TRUSTED] section
G:\Program Files\Microsoft Games\Microsoft Flight Simulator X\GAUGES\Bell_206B.DLL.cktzanrqbabrbuultwcuozchutwwnqnulucrubhu=2
Key aspect - Line ends with =2 for a fully granted gauge.

Last edited:
I think I've narrowed it down to the WinSxS mess up for SimConnect.dll as I've written a simple console app to connect and it wont run, suggesting he "reinstall the application" which suggests it can't find the dll.

It's definitely down to the WinSxS. I built two copies of the Open-Close sample linking to RTM and SP2. The RTM worked and SP2 didn't.

A quick workaround is to copy the SP2 SimConnect.dll into the gauges folder, but obviously this has consequencies if other gauge dlls can't open SimConnect SP1 through the WinSxs system and will fail to load the local SP2 copy as well.

It seems Pete Dowson's repair method is the best long-term solution, but I dread having to suggest to novice customers that they need to go into Windows system directories and do all that.

Hi Folks

Doh ! :eek:

Dependency Walker was what I was thinking of
when I'd typed Listdlls.exe
It's even sat on my desktop. :eek:

Cheers Etienne for the reminder. :)

Most devs will already have it installed,
as its included in all the MS programing Studios, OS Resource Kits, Support Kits, SDKs, etc.

Latest version is v 2.2.6000 29/10/2006.

Just click Start/Run
and type depends

Last edited:
Ok. I shall add that to my list of troubleshooting advice for customers having difficulty with it.

It's a shame that there doesn't appear to be any info out there on the nature of the SimConnect WinSxS fault, only advice on how to fix it via uninstalling SPs, repairings, etc. It might be easier to figure out a more straightforward fix. I guess searching for and dynamically linking the right SimConnect version is a more rugged approach, but it's unfortunate it's necessary.


Lefteris Kalamaras

Staff member
FSDevConf team

you could try having the user install the SP2 simconnect.msi, which exists (once the SP2 SDK is installed) in

Core Utilities Kit\SimConnect SD\lib

that should fix any SxS discrepancies (provided that FSX SP2 *has* been installed correctly).

You *cannot* include this installer with your apps unfortunately, due to licensing issues, although I've seen more than one developer actually do that "silently" through their installer (and if you do it smartly, it doesn't even show afterwards).
I've done away with loading manifests automatically and now parsing the WinSxS folders to find what the client has installed, and using manual dynamic bindings to the dll rather than using the .lib included in the sdk.

The other thing I found out I had to check was the C++ runtime libraries as well, as that's a dependency not always installed, or possibly clobbered if the client happens to have Visual Studio installed.

It's sad even with the good intent of WinSxS, we still get into problems. Granted, if we had the ability to redistribute the simconnect.msi file, that would save a lot of trouble, alas, licensing is licensing.