Same issue here on Windows 10 x64 after a reinstall of GSX. Couldn't it be related to a corrupt file on your side? Since these issues rise since a couple of days?
Before replying to users reporting such problem, I ALWAYS check if the problem can be replicated, doing exactly what the user said it did, for example reinstalling GSX so, if the file was really corrupted on our side, it would be immediately noticeable.
In addition to that, all our executables are digitally signed, so you don't have to "guess" if a file might have been corrupted or you got a bad download, because if you had, the digital signature would become invalid, and you'll see a warning from FSX that the publisher is unknown, which should alert you that something is not right with the file. If you haven't got that warning and you saw the normal request to authorize the module, with the "Virtuali" signature, you can be sure that's nothing is corrupted.
We HAD a small change in the installer though, and I suspect this might have something to do with your error.
Following a user report of a problem of the installer crashing when trying to write the DLL.XML file, that happened ONLY on Windows in Slovak language (nobody ever reported it before, and I couldn't reproduce the crash with the user file on my system, which leads to believe Windows treats XML files a bit different on some OS versions), we decided to make a small change and, instead of always placing the bglmanx.dll line as the first entry in the DLL.XML file (like we used to), the line will now placed at the end.
This fixed the issue immediately for that user, and he told me this change would grant us the gratitude of a whole forum in Slovakia, when everybody basically had that error and couldn't install anything from FSDT.
I do recall that we had to place bglmanx.dll always on top, because another 3rd party module had a problem that, anything loaded after it and using a different version of the Simconnect library, would crash. I *think* it was FS Copilot, but I'm not 100% sure. In any case, I assumed that after all these years, no developer would still use the original Simconnect anymore (the version we use has been released in 2007), considering that is also slower, since it always used a TCP connection, even when no networking was involved, and of course it has less features and many bugs.
Under NORMAL conditions, the loading order shouldn't matter but, it's POSSIBLE (this is just a guess) that, if you have OTHER 3rd party modules that are linked against an OLDER version of the Simconnect library, which now are loaded *before* the Addon Manager, the Windows Side-by-side mechanism, which is supposed (WHEN IT WORKS), to allow multiple versions of the same .DLL to be and run in the same memory address space at the same time, is not working correctly and, the fist module loaded will load the outdated version, and so bglmanx.dll will be forced to run with that version too, even if it has specifically indicated to Windows it needs the CURRENT one.
That's why you are seeing the error about Simconnect_text() not found. This API call wasn't available in the original Simconnect RTM, the one that was included with plain FSX before any Service Packs. It was added only with the SP1 and beyond.
The most likely explanation of this is that, because another 3rd party module that uses the original Simconnect is loading *before* bglmanx.dll, your FSX will load the old Simconnect, but it won't re-load the new one when bglmanx.dll asks for it. SInce the old one doesn't have the Simconnect_text() function, you get that error.
Unfortunately, the DLL.XML file I used for testing, which includes many other 3rd party modules, like the ones from PMDG, FSUIPC, Aerosoft, Level-D, FSX, VRS, doesn't have any problems, regardless if I place the bglmanx.dll at the start or at the end of the file. And this is how is supposed to work but, maybe, none of these modules is trying to load the old Simconnect, so no conflicts happens.
There would be an easy way to test this, for those affected:
- Open your %APPDATA%\Microsoft\FSX\DLL.XML file
- Look for these lines ( they are probably on the bottom of the file now:
<Launch.Addon>
<Name>Addon Manager</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>bglmanx.dll</Path>
</Launch.Addon>
Cut all these lines (from the <Launch.Addon> tag to the </Launch.Addon> closing tag), and paste them as the first section, after the first lines of the file, so it will end up to something similar to this:
<?xml version="1.0" encoding="windows-1252"?>
<SimBase.Document Type="Launch" version="1,0">
<Descr>Launch</Descr>
<Filename>dll.xml</Filename>
<Disabled>False</Disabled>
<Launch.ManualLoad>False</Launch.ManualLoad>
<Launch.Addon>
<Name>Addon Manager</Name>
<Disabled>False</Disabled>
<ManualLoad>False</ManualLoad>
<Path>bglmanx.dll</Path>
</Launch.Addon>
<Launch.Addon>
....
</Launch.Addon>
<Launch.Addon>
....
</Launch.Addon>
<Launch.Addon>
....
</Launch.Addon>
<Launch.Addon>
....
</Launch.Addon>
<Launch.Addon>
....
</Launch.Addon>
</SimBase.Document>
If we are lucky, and the theory of the loading order is correct, it might fix your error. If not, then I've guessed wrong, and the problem lies elsewhere.
