Is GSX supposed to woerk now with FSX-SE build 62610 (Open Beta)?

[Pete Dowson]

Hi,

From what i read, the current AddonManager install should allow GSX to work fine with the new open Beta version of FSX-SE. Is that right? If so I can report remaining problems.

When trying to select almost any entry in the GSX menu, on ground and parked ready for boarding etc, I get a couatl.exe crash, reported as an access attempted to 0x00000000 at process address 0x004028F6. That one was when simple asking for boarding to commence. I must admit I already had the doors open.

I've had to abandon AES, for which I have nearly all supported airports subscribed, and had hoped GSX would fill in the gap well. I would be eagerly looking out for updates to fix these problems.

Thanks,
Pete Dowson

[virtuali]

From what i read, the current AddonManager install should allow GSX to work fine with the new open Beta version of FSX-SE. Is that right? If so I can report remaining problems.

Yes, FSX:SE build 62610 is supported.

When trying to select almost any entry in the GSX menu, on ground and parked ready for boarding etc, I get a couatl.exe crash, reported as an access attempted to 0x00000000 at process address 0x004028F6. That one was when simple asking for boarding to commence. I must admit I already had the doors open.

I cannot reproduce it, but I only have default airplanes in FSX:SE. Which airplane you used ?

Couatl.exe doesn't access FSX memory directly, so it's not affected in any way by the specific build of the sim. It gets data "by proxy", with the help of the Addon Manager which, instead, does access memory directly and so it IS affected by the specific build of the sim. However, if the problem was the Addon Manager, you would have seen a crash in bglmanx.dll and it would have brought down the whole FSX with it.

One thing is not currently supported under FSX:Steam, any version, and it's the "Restart Couatl" feature. That would cause an access violation. We finally found what's causing it (it only happens under Steam), and will surely be fixed with the next version of Couatl.exe, but other than that, I don't know of any other known issues with it.

Does it happen with any airplane ? Try for example a default airplane on a default airport.

It might be also something entirely unrelated to FSX or Steam, for example an issue with sound drivers. GSX requires OpenAL, and a problem with OpenAL support in the sound card will likely cause Couatl to crash.

[Pete Dowson]

I cannot reproduce it, but I only have default airplanes in FSX:SE. Which airplane you used ?

I use Prosim737 Pro version, specifically designed to work with Prosim737 cockpit systems.

Couatl.exe doesn't access FSX memory directly, so it's not affected in any way by the specific build of the sim. It gets data "by proxy", with the help of the Addon Manager which, instead, does access memory directly and so it IS affected by the specific build of the sim. However, if the problem was the Addon Manager, you would have seen a crash in bglmanx.dll and it would have brought down the whole FSX with it.

About 1 in 3 times starting FSX-SE, it just hangs on the splash screen, and I have to terminate it via Task Manager. It always loads next attempt, but gives the warning that bglmanx.dll caused a problem, and I have to tell it to load it in any case. So maybe it is related to this problem? I've not been able to find any details of why FSX-SE thought BGLMANX was a problem.

One thing is not currently supported under FSX:Steam, any version, and it's the "Restart Couatl" feature.

Yes, I did read about that and avoid using it.

Does it happen with any airplane ? Try for example a default airplane on a default airport.

I don't have many other aircraft installed on my cockpit system, but I'll copy over the default 738 from my development PC and try that.

It might be also something entirely unrelated to FSX or Steam, for example an issue with sound drivers. GSX requires OpenAL, and a problem with OpenAL support in the sound card will likely cause Couatl to crash.

But GSX is working fine on the same PC with the same aircraft and airports when using FSX. I have both FSX and FSX-SE operational on my cockpit, but now prefer FSX-SE because it is faster and smoother with my dense airports, full AI (MyTrafficX) and complex weather from ASN.

Regards
Pete

[virtuali]

About 1 in 3 times starting FSX-SE, it just hangs on the splash screen, and I have to terminate it via Task Manager. It always loads next attempt, but gives the warning that bglmanx.dll caused a problem, and I have to tell it to load it in any case. So maybe it is related to this problem? I've not been able to find any details of why FSX-SE thought BGLMANX was a problem.

I cannot reproduce any bglmanx.dll crashes in FSX:SE. In fact, since we moved to using VC++ 2013 runtime libraries, we never had any more reports of that error, since the chance of issues with SxS would be much lower, since FSX:SE uses the same libraries.

So, it's possible your problem has been caused by another module, which is using other runtimes, so it's just the old issue of different VC++ runtimes loaded at the same time, in-process.

Is that cockpit software made using different/older version of the VC++ runtime libraries ?

We had users on FSX, using the GoFlight instrument drivers, which had issues ONLY when using them together with our module and they fixed it by altering the order of loading or (because GoFlight software is an .exe that is started by EXE.XML ), by starting it manually after FSX started.

So, perhaps, this is a similar issue. Have you tried disabling any other module in both XML files, then re-enabling them, one by one ?

[Pete Dowson]

I cannot reproduce any bglmanx.dll crashes in FSX:SE. In fact, since we moved to using VC++ 2013 runtime libraries, we never had any more reports of that error, since the chance of issues with SxS would be much lower, since FSX:SE uses the same libraries.

So, it's possible your problem has been caused by another module, which is using other runtimes, so it's just the old issue of different VC++ runtimes loaded at the same time, in-process.

Hmm. I'll try a process of elimination. But BGLMANX doesn't appear to crash, it just stops FSX-SE continuing, i.e. some sort of hang or deadly embrace. There's no sign of crash reports in Windows event viewer. I only say it is BGLMANX because FSX-SE asks me next time, saying it caused a problem do I want to load it ... if then I say yes, it all works.

Is that cockpit software made using different/older version of the VC++ runtime libraries ?

It isn't running on the same PC, it is on another PC via WideFS. There is a separate process operating the autopilot (ProsimMCP) on the FSX PC. There are no components of Prosim which run inside the FSX process.

So, perhaps, this is a similar issue. Have you tried disabling any other module in both XML files, then re-enabling them, one by one ?

Not yet. I will be doing testing this week, both for the BGLMANX problem and the COUATL crash.

Pete

[virtuali]

But BGLMANX doesn't appear to crash, it just stops FSX-SE continuing, i.e. some sort of hang or deadly embrace. There's no sign of crash reports in Windows event viewer. I only say it is BGLMANX because FSX-SE asks me next time, saying it caused a problem do I want to load it ... if then I say yes, it all works.

That's exactly how it happened with the other user with GoFlight, when we were still using the VC++ 2005 runtimes, while GoFlight is a bit of a mess, because I think it uses several versions at once (it installs multiple runtimes). In that case, FSX just hung up, and it came out with the usual "bglmanx.dll might be not safe", which is the generic panic message from FSX when a module cannot be loaded for any reason, in this case because of SxS issue.

It isn't running on the same PC, it is on another PC via WideFS. There is a separate process operating the autopilot (ProsimMCP) on the FSX PC. There are no components of Prosim which run inside the FSX process.

GoFlight software is not in-process either, and it caused a very similar issue on that user system, unless it was loaded manually after starting FSX. In fact, it was the fact it runs out-of-process, which allowed to fix it by loading manually.

[Pete Dowson]

In that case, FSX just hung up, and it came out with the usual "bglmanx.dll might be not safe", which is the generic panic message from FSX when a module cannot be loaded for any reason, in this case because of SxS issue.

Ah, slightly different. This one is the "has detected a problem with", no mention of safety. I tried moving the position of BGLMANX loading in the DLL.XML later, but though it seemed then to be a little better (hanging 1 in 3 instead of 1 in 2 loads), it obviously isn't happy. The only other DLLs loading are:

LHBP Objectplacer
Traffic Toolbox
A2A Feel
Accufeel Menu
AI Dupe
ASE-Data
FSUIPC4
as-bstrp

bglmanx.dll is usually first to load, before all those.

The only EXE loaded by EXE.XML is couatl.exe.

GoFlight software is not in-process either, and it caused a very similar issue on that user system, unless it was loaded manually after starting FSX. In fact, it was the fact it runs out-of-process, which allowed to fix it by loading manually.

All my other out-of-process loads are done by FSUIPC, long after the bglmanx.dll hang.

I've just reverted FSX-SE to 62608 and it's exactly the same there.

More of concern to me, actually, is the COUATL crash, which I can't get past at all, unlike the bglmanx problem. It crashes, 100% on any and every airport memu selection. I can select any item, it is confirmed in the red message at the top, and then the crash occurs. Always "the instruction sat 0x004028F6 attempted to access memory at 0x00000000. Ie the normal null pointer sort of problem.

Unfortunately the crash doesn't produce an entry in the Wiindows logs -- I assume that's because it's trapped in-process. So I used the VS10 debugger to at least trace events leading to the crash, appended the log it produced.

Hope it can be solved. With AES totally useless in FSX-SE GSX is the only choice! :-(

Regards
Pete

===============================================================
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\couatl.exe', No symbols loaded.
'couatl.exe': Loaded 'C:\Windows\SysWOW64\ntdll.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\kernel32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\KernelBase.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\user32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\gdi32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\lpk.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\usp10.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\msvcrt.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\advapi32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\sechost.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\rpcrt4.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\sspicli.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\cryptbase.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\oleaut32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\ole32.dll', Symbols loaded.
'couatl.exe': Loaded 'C:\Windows\SysWOW64\shell32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\shlwapi.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\version.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.flightsimulator.simconnect_67c7c14424d61b5b_10.0.61259.0_none_55f5ecdc14f60568\SimConnect.dll', Exports loaded.
'couatl.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\msvcr80.dll', Symbols loaded.
'couatl.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\msvcp80.dll', Symbols loaded.
'couatl.exe': Loaded 'C:\Windows\SysWOW64\ws2_32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\nsi.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\shfolder.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\wininet.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\api-ms-win-downlevel-user32-l1-1-0.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\api-ms-win-downlevel-advapi32-l1-1-0.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\api-ms-win-downlevel-shlwapi-l1-1-0.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\api-ms-win-downlevel-version-l1-1-0.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\api-ms-win-downlevel-normaliz-l1-1-0.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\normaliz.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\iertutil.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\python25.dll', Exports loaded.
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\OpenAL32.dll', Exports loaded.
'couatl.exe': Loaded 'C:\Windows\SysWOW64\winmm.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\alut.dll', Exports loaded.
'couatl.exe': Loaded 'C:\Windows\SysWOW64\imm32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\msctf.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'E:\Steam\GameOverlayRenderer.dll', Exports loaded.
'couatl.exe': Loaded 'C:\Windows\SysWOW64\psapi.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.common-controls_6595b64144ccf1df_5.82.7601.18201_none_ec80f00e8593ece5\comctl32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\profapi.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\wx\_core_.pyd', Exports loaded.
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\wx\wxmsw28uh_vc.dll', Exports loaded.
'couatl.exe': Loaded 'C:\Windows\winsxs\x86_microsoft.windows.gdiplus_6595b64144ccf1df_1.1.7601.18120_none_72d2e82386681b36\GdiPlus.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\comdlg32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'C:\Windows\SysWOW64\wsock32.dll', Symbols loaded (source information stripped).
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\wx\_gdi_.pyd', Exports loaded.
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\wx\_windows_.pyd', Exports loaded.
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\wx\_controls_.pyd', Exports loaded.
'couatl.exe': Loaded 'E:\Steam\steamapps\common\FSX\fsdreamteam\couatl\wx\_misc_.pyd', Exports loaded.
'couatl.exe': Loaded 'C:\Program Files (x86)\Stardock\ObjectDock\DockShellHook.dll', Exports loaded.
The thread 'Win32 Thread' (0x196c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x760) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xd84) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1110) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xe70) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1528) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x75c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1070) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x12c8) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1a3c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xb94) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x19a8) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x15fc) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1b34) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x109c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1624) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x13e0) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1220) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x142c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1004) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x2dc) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x5c8) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1320) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x14f8) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1604) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1bac) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1384) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0xd8c) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x848) has exited with code 0 (0x0).
The thread 'Win32 Thread' (0x1980) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x398) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x1598) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0xcd4) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x1684) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x14ec) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x1564) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x814) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x135c) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x58c) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x1668) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x554) has exited with code -1073741819 (0xc0000005).
The thread 'Win32 Thread' (0x1394) has exited with code -1073741819 (0xc0000005).
The program '[5840] couatl.exe: Native' has exited with code -1073741819 (0xc0000005).
=======================================================

[virtuali]

Ah, slightly different. This one is the "has detected a problem with", no mention of safety. I tried moving the position of BGLMANX loading in the DLL.XML later, but though it seemed then to be a little better (hanging 1 in 3 instead of 1 in 2 loads), it obviously isn't happy. The only other DLLs loading are:

LHBP Objectplacer
Traffic Toolbox
A2A Feel
Accufeel Menu
AI Dupe
ASE-Data
FSUIPC4
as-bstrp

bglmanx.dll is usually first to load, before all those.

The only EXE loaded by EXE.XML is couatl.exe.

Have you tried with everything disabled ? At least to exclude the chance it's a conflict with another module.

More of concern to me, actually, is the COUATL crash, which I can't get past at all, unlike the bglmanx problem. It crashes, 100% on any and every airport memu selection. I can select any item, it is confirmed in the red message at the top, and then the crash occurs. Always "the instruction sat 0x004028F6 attempted to access memory at 0x00000000. Ie the normal null pointer sort of problem.

As I've said, since I cannot reproduce it, it must be some kind of a problem with your system or some of your files.

First, try to trash all the preferences, it's possible that a corrupted .ini file might cause the program to crash. To remove all GSX preferences, remove these folders:

%appdata%\Virtuali
%programdata%\Virtuali

Note that, by doing this, you'll lose all your airport and airplane customization you might have done so, you might want to MOVE the folders away, rather than removing them.

At the next FSX startup, GSX should start regenerating the cache, and it's possible a corrupted .BGL might cause a crash too, so this is worth checking.

Unfortunately the crash doesn't produce an entry in the Wiindows logs -- I assume that's because it's trapped in-process. So I used the VS10 debugger to at least trace events leading to the crash, appended the log it produced.

Trying to use it under a debugger will *guarantee* a crash, that's to be expected.

[Pete Dowson]

Have you tried with everything disabled ? At least to exclude the chance it's a conflict with another module.

Yes, everything except FSUIPC anyway. Actually, I've disabled Accu-Feel altogether now and it seems to be better. No hangs so far ...

As I've said, since I cannot reproduce it, it must be some kind of a problem with your system or some of your files.

Right. But doesn't the location of the crash tell you anything at all? It is always the same place. Wouldn't that at least give a clue?

First, try to trash all the preferences, it's possible that a corrupted .ini file might cause the program to crash. To remove all GSX preferences, remove these folders:

%appdata%\Virtuali
%programdata%\Virtuali

But aren't they the same folders used by the software with FSX-MS? GSX works perfectly still in FSX-MS on the same PC! So 100% consistent crash in couatl on FSX-SE, no crash at all, ever, in FSX-MS.

Trying to use it under a debugger will *guarantee* a crash, that's to be expected.

Okay, so the only diagnostic information you have so far is the location and the fact of the zero pointer. I've located problems in FSUIPC with such scant information, which do help point to the cause whether internal or not.Not so with your programming?

Regards
Pete

[virtuali]

Right. But doesn't the location of the crash tell you anything at all? It is always the same place. Wouldn't that at least give a clue?

Yes, it might, but before reverting to that, maybe there are easier way to find issue. Try to enable Couatl log file, which you can do manually (assuming you cannot access the Couatl menu inside FSX, since it crashes) this way:

create a new blank file:

logFile=couatl.log

(please note logFile is written beginning with a lower case l and a capital F )

Save the file as COUATL.INI in the FSX\fsdreamteam\couatl folder, so it stays at the same level of the couatl.exe

After a run, check your %APPDATA%\Virtuali folder for a Couatl.LOG and a Couatl.ERR file and attach them here (in a .ZIP file, since the forum requires that)

[Pete Dowson]

I just had my first bglmanx.dll hang on loading since removing the accu-feel modules from the DLL.EXE. So all those things, removing possible conflicts, just seems to reduce the chance of a hang, not eliminate it. :-(

After a run, check your %APPDATA%\Virtuali folder for a Couatl.LOG and a Couatl.ERR file and attach them here (in a .ZIP file, since the forum requires that)

By "after a run" I assume you mean after getting the couatl crash?

I attach a ZIP containing the log, which was actually in the same fsdreamteam\couatl folder as the INI I made, plus a couatl.err file I did find in %APPDATA%\Virtuali, but not generated just. Looks like it was generated last time I tried running addon manager install to see if that would fix the problems.

I also notice that there is a specific FSXSE folder in the couatl folder in %PROGRAMDATA%\Virtuali, so I've renamed that and trying again ...

... No, same. And it remade the folder with the same identical files but today's date/time.

So I also tried renaming the APPDATA folder. Same there.

Pete

[virtuali]

I just had my first bglmanx.dll hang on loading since removing the accu-feel modules from the DLL.EXE. So all those things, removing possible conflicts, just seems to reduce the chance of a hang, not eliminate it. :-(

Have you tried starting from nothing (no modules except FSDT ones), and adding up ? I mean totally clean DLL.XML and EXE.XML, including turning off FSUIPC momentarily, just to be sure, then adding one module at time ?

I still think the real problem is not Couatl.exe crash, which is more as a consequence of something happening before.

I just had a Teamviewer session with an user, and in this case, the problem module was FS Recorder, which couldn't work together with bglmanx.dll, but this was P3D, and FS Recorder is not really tested for it, so this might be related or not, but I'll always try to test by exclusion, starting with a DLL.XML with everything disabled first, then adding up.

Another user had the same "problem raised by engine or unspecified addonBglmanx disconnected prematurely" that you have in your Couatl.err file, and in one case it was related to FSUIPC, in another case to the sim "Affinity" mask setting:

http://www.fsdreamteam.com/forum/index.php/topic,10152.msg79388.html#msg79388

[Pete Dowson]

Have you tried starting from nothing (no modules except FSDT ones), and adding up ? I mean totally clean DLL.XML and EXE.XML, including turning off FSUIPC momentarily, just to be sure, then adding one module at time ?

Yes. with no other EXEs loaded OR running other than FSX-SE and COUATL, and no other add-in DLLs than BGLMANX, exactly the same error occurs, 100% consistently.

However, I have found the problem, at long last!

Because I share everything between FSX-MS and FSX-SE, all my scenery paths are the same full paths on both Scenery.CFG files, and, to the point here, so are all my SimObjects paths.

It appears COUATL.EXE crashes if the path from which certain SimObjects are loaded is NOT the default, the one inside the current FSX folder! I assume its the ground vehicles path, but I restored them all except MyTraffic and my own added "MyAirplanes" entries to point to FSX-SE 's folders, and then there's no crash, everything works.

All the other application which use these folders, FSX included, use the actual path as specified, but not COUATL. I don't suppose you are likely to want to change that (complications, like searching the FSX CFG file for the path entry), which is a shame as it means less commonality between two otherwise almost identical installations (FSX-MS and FSX-SE), but at least I know know how to get around this restriction.

[LATER]
Another thought. I don't suppose I could have COUATL.EXE run from the FSX\DreamTeam folder instead of the FSX-SE one, even when running FSX-SE? It would presumably then find the correct objects, but would it then get confused in other ways?

Regards
Pete

[virtuali]

It appears COUATL.EXE crashes if the path from which certain SimObjects are loaded is NOT the default, the one inside the current FSX folder! I assume its the ground vehicles path, but I restored them all except MyTraffic and my own added "MyAirplanes" entries to point to FSX-SE 's folders, and then there's no crash, everything works.

You mean you just changed the SimObjectPath lines to point to another folder ? I tried doing that, for all lines, and changed them to point to my FSX installation, like this:

[Main]
User Objects=Airplane, Helicopter
SimObjectPaths.0=c:\fsx\SimObjects\Airplanes
SimObjectPaths.1=c:\fsx\SimObjects\Rotorcraft
SimObjectPaths.2=c:\fsx\SimObjects\GroundVehicles
SimObjectPaths.3=c:\fsx\SimObjects\Boats
SimObjectPaths.4=c:\fsx\SimObjects\Animals
SimObjectPaths.5=c:\fsx\SimObjects\Misc

FSX-SE is installed under the default Steam folder, FSX is in C:\FSX

And couldn't see any crashes either, everything worked normally. Do your paths looks similar to that ?

[virtuali]

Could you please try the attached file, to be placed into the fsdreamteam\Couatl\common folder ?

Even if I still cannot reproduce a crash, I think we found a difference between the FSX Simconnect and the FSX-SE Simconnect, and they don't report the airplane path in the same way so, this updated file should handle both cases.