BGLMANX hangs during FSX-SE loading 50-75% of attempts

[Pete Dowson]

Let me say, at the start, that I've always had a problem with BGLMANX hanging during FS loading -- both FSX and FSX-SE.  It used to be relatively infrequent, and on retrying the FSX load I just get a message saying there was a problem with BGLMANX, do I want to run it yes/no (yes not advised), and when that happens selecting yes has invariably worked. It was so infrequent I ddn't want to bother anyone about it.

Since the last AddOn Manager release, using FSX-SE 62615 build, the occurrence of this problem has increased in frequency dramatically, and sometimes it takes me 4 or 5 or more (more this afternoon!) attempts to get FSX-SE started!

I've tried moving the Addon Manager entry to different places in the DLL.XML but it makes no difference.

Is there anything known about such problems? Is there an answer? I've given up even trying to fly today as I've used so much time up just trying to get the Sim loaded.

In case there's some sort of (new?) known clash with any of the other DLL's being loaded, I append my DLL.XML file.  I think the only other module to have been recently updated (apart from FSUIPC4 of course, which I'm always updating) is "ObjectFlow.DLL". But the hang occurs before it gets there -- I know this because when an updated FSUIPC4 is installed I get the usual prompt to approve it, and with BGLMANX hanging before that occurs I know ObjectFlow hasn't been loaded. Also it makes no different if I disable ObjectFlow.

Thanks for any help you can offer in this matter,

Pete



<?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>
    <Name>Traffic Toolbox</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>SDK\Environment Kit\Traffic Toolbox SDK\traffictoolbox.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>RAASPRO</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <DLLStartName>module_init</DLLStartName>
    <DLLStopName>module_deinit</DLLStopName>
    <Path>RAASPRO\RAASPRO.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>AIDupe</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>Modules\AIDupe.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>SODE Animation Module</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>E:\Steam\steamapps\common\FSX\SODE\SimObjectAnimationModule.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>FSUIPC 4</Name>
    <Disabled>False</Disabled>
    <Path>Modules\FSUIPC4.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>ObjectFlow.dll</Name>
    <Disabled>False</Disabled>
    <ManualLoad>False</ManualLoad>
    <Path>E:\FSX\ORBX\FTX_AU\FTXAA_ORBXLIBS\Scenery\ObjectFlow.dll</Path>
  </Launch.Addon>
  <Launch.Addon>
    <Name>as_connect</Name>
    <Disabled>False</Disabled>
    <Path>as_srv\as_btstrp.dll</Path>
  </Launch.Addon>
</SimBase.Document>

[virtuali]

Pete,

I just tried doing the following test: launching FSX:SE ( 62615 final ), 10 times in a row. I couldn't see any errors. I have the following modules in the DLL.XML, in this order:

bglmanx.dll
ObjectFlow.dll
PMDG_HUD_Interface.dll
as_btstrp.dll
FSUIPC4.dll

Maybe you can try disabling everything except bglmanx.dll and FSUIPC.dll, and see if the error still comes out. If not, start re-enabling all your other modules, one by one, until the error comes out again.

[Pete Dowson]

Maybe you can try disabling everything except bglmanx.dll and FSUIPC.dll, and see if the error still comes out. If not, start re-enabling all your other modules, one by one, until the error comes out again.

Well, I will do. but it's odd -- It's only been happening frequently since the recent AddonManager update. I've been using 62615 with it happening only very infrequently for weeks. Symptoms like this indicate some sort of timing dependency, a thread lock or something similar.

I'll let you know what I find. Trouble is I can't see any way to see where or why it hangs. you don't have any logging at all, do you, to narrow things down?

Pete

[virtuali]

It's only been happening frequently since the recent AddonManager update. I've been using 62615 with it happening only very infrequently for weeks. Symptoms like this indicate some sort of timing dependency, a thread lock or something similar.

If you saw the typical message about a 3rd party module having a problem and might not be safe to load (which I randomly get from *every* module, including FSUIPC, but not only, but so rarely that I don't really care), it's just a "panic" message from FSX that it cannot load the .DLL so, it's happening even before that .DLL had a chance to execute a single line of code.

Most of the times, it's the WinSxS system that had an issue, like being confused which version of a side-by-side library it's supposed to load.

So, this is what usually causes the "3rd party module not safe" error. At that point, when you are being asked the question about running it, unless you reply "Yes", the module still haven't got a chance to execute any of its code.

After you reply Yes, crashes might both happening because there IS a problem with the module code, but they might also happen because the module got the wrong version of the CRT, which caused the first warning to come up.

I'll let you know what I find. Trouble is I can't see any way to see where or why it hangs. you don't have any logging at all, do you, to narrow things down?

Yes, of course I have a logging version, I'll contact you with PM about it.

[Pete Dowson]

If you saw the typical message about a 3rd party module having a problem and might not be safe to load (which I randomly get from *every* module, including FSUIPC, but not only, but so rarely that I don't really care), it's just a "panic" message from FSX that it cannot load the .DLL so, it's happening even before that .DLL had a chance to execute a single line of code.

No, this isn't random. That message only appears AFTER an attempted load of FS has hung.  I've never actually had it with any other module, and using ProcMon to see where it gets to when it does hang, it is always on BGLMANX. [As an aside, I've never ever managed to get the loading problem with FSUIPC4 on any of 5 different systems here, which is a pity as I'd like to have nailed that one and it isn't possible without reproducing it].

Most of the times, it's the WinSxS system that had an issue, like being confused which version of a side-by-side library it's supposed to load.

Yes, I got around that by not using the SxS system at all, just finding the SimConnect.DLLs and linking to the one of my choice dynamically, not statically or via manifests.

So, this is what usually causes the "3rd party module not safe" error. At that point, when you are being asked the question about running it, unless you reply "Yes", the module still haven't got a chance to execute any of its code.

I know, and agree. The loading sequence only hangs when it is executing the code. According to "WhatIsHang", which otherwise isn't very helpful, it's on a Windows API call. If I don't get anywhere I'll put my development environment on my cockpit PC to try to trace it and check the stack. But I'd rather not -- I like to keep that PC really clean of clutter not essential to the cockpit environment.

As an experiment, instead of letting SimConnect load it, I made FSUIPC load it and call its "DLLStart" function. That hung in the same way. If I delayed executing it until FS is "ready to fly" it crashes instead, so I gave up trying that way --- I assume it needs to get in before something else happens, possibly from COUATL.EXE?

And that's a thought too. It might not be another DLL loading and interacting (in fact, seeing as BGLMANX is usually my first loaded DLL it seems extremely unlikely). It might be one of the antics of the EXE's loaded by EXE.DLL. I've just remembered that those are loaded by SimConnect before the DLLs.

I'll try without the EXE.DLL and see what happens, loading the EXEs I need later. Come to think of it, I've only just recently started using Ultimate Traffic 2 again. It puts its UT2Services.exe in there. Hmm. Suspicious. I'll try without that. I can always start that later using FSUIPC ....

I'll report later, after some more experiments.

Yes, of course I have a logging version, I'll contact you with PM about it.
[/quote]

Right'O. That might be useful. I'll carry on with the elimination in the mean time.

Thanks & Regards
Pete

[virtuali]

No, this isn't random. That message only appears AFTER an attempted load of FS has hung.  I've never actually had it with any other module, and using ProcMon to see where it gets to when it does hang, it is always on BGLMANX. [As an aside, I've never ever managed to get the loading problem with FSUIPC4 on any of 5 different systems here, which is a pity as I'd like to have nailed that one and it isn't possible without reproducing it].

It is random for me, and it can happen with every module ( pmdg, fsuipc, leveld, etc. ) but it happens so rarely, that I just think it's happening because I launch and quit FSX and/or Visual Studio, and debug it, like 100 times at day, so I fully expect that something might go wrong with the libraries.

Yes, I got around that by not using the SxS system at all, just finding the SimConnect.DLLs and linking to the one of my choice dynamically, not statically or via manifests.

I know, but I wanted to use the "official" way of doing things ( shared .dll + manifest ) before venturing in something so complex, which will also require a separate .dll *just* for P3D...

As an experiment, instead of letting SimConnect load it, I made FSUIPC load it and call its "DLLStart" function. That hung in the same way. If I delayed executing it until FS is "ready to fly" it crashes instead, so I gave up trying that way --- I assume it needs to get in before something else happens, possibly from COUATL.EXE?

Couatl.exe opens a separate (non Simconnect) pipe of communication with bglmanx.dll, so it won't try to do anything with it, unless bglmanx.dll will tell it's fully loaded, and ready to talk, so I don't think Couatl.exe should have anything to do with this.

I'll try without the EXE.DLL and see what happens, loading the EXEs I need later. Come to think of it, I've only just recently started using Ultimate Traffic 2 again. It puts its UT2Services.exe in there. Hmm. Suspicious. I'll try without that. I can always start that later using FSUIPC ....

Maybe it's unrelated, but I had an user having a problem with bglmanx.dll hanging and another 3rd party module in the EXE.XML, and it was the GoFlight drivers. Those drivers don't seem to have a clear idea what they need, because their installer installs *ALL* VC++ runtimes known to man...from 2005 to 2010, which seems to be quite messy.

The only way to fix this, was to start the GoFlight drivers manually (not from the EXE.XML), after FSX loaded.

This seems to indicate another kind of issue with Side-by-side, maybe depending on loading order too.

[Pete Dowson]

Okay, I think I've resolved it, for my system anyway.

I stopped all EXE's loading in the EXE.XML except COUATL, and made sure BGLMANX was the first in the DLL.XML.

Result: 100% success on FSX-SE loading!

Added only the UT2Services.exe back into the EXE.XML.

Result: 100% failures, at least on 4 tries before I gave up and decided this was pretty conclusive.

Something about what UT2Services does, loading before BGLMANX, is screwing things up.

Why this only seems to affect BGLMANX, no other DLLs being loaded, I don't understand. I tried your logging version and it didn't log anything when it hung, but it looks like you only start the log on the DLLStart. Maybe there's something going on in the DLLMain function, the one called automatically by Windows when the DLL is loaded?

In FSUIPC4 I experimented quite a bit in the early days with what code I did in DLLMain, BEFORE being called at DLLStart by SimConnect, and what I did in the DLLStart routine. I think, to check what is so different with BGLMANX, that would be the place to start.

Anyway, for the time being at least I'm happy to have a working setup again. I've actually now moved ALL of the EXE starts, except COUATL, to my FSUIPC [Programs] loading section.

Thanks & Best Regards
Pete

[edwardpat]

Hi, Pete, sorry for comment on your post, but in my opinion I do not think in some way that you have completely solved your problem, since it seems that you would still have a conflict with another app you're using (in your case UT2), and probably what you have done so far is to find out which is the conflicting module, but really the root cause of it is still to be found. Only because you have the required knowledge you have found a way to overpass it.

I'm having a similar issue on my system. I run P3Dv2.5 and I had to temporarily take the suspected bglmanx.dll module out of the main directory of P3D (and this of course do not let me in any way to use any of the FSDT addons I have), to be able to avoid the hang-ups during the P3D start sequence and open the simulator (see my other post). This has hapenned to me frequently before the recent uodate of the GSX installer, but know it happens 100% of the time and is quite annoying. When I take out the bglmanx.dll file, the simulator starts Ok 100% of the time, which is in my opinion very conclusive.

Hopefully FSDT will do whatever is necessary to help correct this issue.

Best regards,

Edward

BTW: Congrats for your very well known FSUIPC module, an old companion for us all FS hobbyists.

[Pete Dowson]

Hi, Pete, sorry for comment on your post, but in my opinion I do not think in some way that you have completely solved your problem

No, only "solved" for my system (as it is at present), as I said.

Hopefully the more feedback provided about the problem, the more likely it is to be solved properly.  Even if it needs attention by Lockheed-Martin for P3D or DoveTail for FSX-sE -- at least there are still developers working on FS these days, so even that's a possibility. But it needs narrowing down to a specific cause first.

You should really do the same, find out which other add-on is involved in the conflict. Just not using BGLMANX is not so helpful is it?

Regards
Pete