Losing flight controls in FSX....

[Gypsy Baron]

Hello Pete,

I've been having some problems during my FSX flights

that seem to occur most often after 1+ hours of flight.

What happens is that I lose input to FSX of my stick,

rudder and throttle controls ( Saitek X-45 ).

The stick/throttle buttons still work but the axis

inputs are gone. I can control throttle, etc with

keyboard commands.

One symptom that the problem has occured is the

existance of multiple menu entries for FSUIPC4,

usually 2, sometimes 3, where only the last entry

is clickable. I can open FSUIPC, make changes, etc

but nothing restores my controls. Re-loading the

flight from the drop-down menu does not cure the

problem nor does selecting a different aircraft.

I must exit flight and FSX and restart.

I was using FSUIPC4 4.06 and last evening I updated

to 4.065. The problem reoccurs with that version also.

I have a registered version, BTW.

FSX has "permission" to access the local net and internet

via my firewall ( ZoneAlarm ) and the problem does not

occur on every flight. Last night I noticed a period

of 3-4 seconds when my cursor movement ceased, indicating

something was "hanging" and after that I saw that my

controls were gone. I then opened a new FSUIPC log,

preserving the previous log that covers the flight from

start until just after the glitch.

Main memory and video ram are OK. Usually around 1.3GB

out of 2 GB and 330MB out of 512MB being used.

It's obvious that this has something to do with Simconnect

and I have noted your mention of problems related to that

FSX function.

The log indicates that comms with SimConnect were lost

4 times and restored. What is curious is the "menu entry

added" events which are noted 5 times. What I saw was

2 FSUIPC menu entries in this case. I'm wondering if

something caused SimConnect to remove the prior entry

instances in 3 cases but not in the last 2, resulting

in the double entry and that this might somehow have

contributed to the loss of controls.

Anyhow, I'd like to resolve this issue and if you have any

suggestions as to what I might do to assist in tracking down

the culprit, just let me know.

Below is the not-to-lenghthy log file.

Regards,

Paul

P.S. - I originally became aware of the need for local net

access when I shut had my firewall "lock" the access when

I noticed activity when running FSX some time ago. It was

then that I first noticed a loss of controls. I then checked

the net for info and saw your comments on the SimConnect

issue and have not "locked" my firewall since :) So,

I at least know how I CAN cause the problem, if this

might help in doing sometroubleshooting, without waiting

for 1-2 hours in-flight.

----------------------------------------------

********* FSUIPC4, Version 4.065 by Pete Dowson *********

User Name="xxxxxxxxx"

User Addr="xxxxxxxxxxx"

FSUIPC Key is provided

WIDEFS not user registered, or expired

Running inside FSX

Module base=61000000

LogOptions=00000001

DebugStatus=15

391 System time = 21:38:56

406 FLT UNC path = "\\BOHEMIA\Cerna Hora\Documents and Settings\GB\My Documents\Flight Simulator X Files\"

406 FS UNC path = "K:\Program Files\Microsoft Games\Microsoft Flight Simulator X\"

2703 SimConnect_Open succeeded: proceeding to initialise interface!

27656 Running in "Microsoft Flight Simulator X", Version: 10.0.60905.0 (SimConnect: 2.0.60905.0)

139187 SimStart Event: Initialising SimConnect data requests

139187 FSUIPC Menu entry added

139609 C:\Documents and Settings\GB\Application Data\Microsoft\FSX\Previous flight.FLT

139609 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\IFR Schiphol to Tempelhof.PLN

139609 K:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Airplanes\JBK Douglas DC6\dc6.AIR

139641 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\IFR Schiphol to Tempelhof.PLN

139672 System time = 21:41:16, FSX time = 03:39:20 (02:39Z)

139906 Aircraft="JBK Douglas DC-6 UAL"

140641 Advanced Weather Interface Enabled

7183547 **** No SimConnect events or states being received! Re-connecting now****

7183625 SimConnect_Open succeeded: proceeding to initialise interface!

7183625 Initialising SimConnect data requests now

7183625 FSUIPC Menu entry added

7183766 **** No SimConnect events or states being received! Re-connecting now****

7183766 SimConnect_Open succeeded: proceeding to initialise interface!

7183766 Initialising SimConnect data requests now

7183766 FSUIPC Menu entry added

7183891 **** No SimConnect events or states being received! Re-connecting now****

7183891 SimConnect_Open succeeded: proceeding to initialise interface!

7183891 Initialising SimConnect data requests now

7183922 FSUIPC Menu entry added

7184047 **** No SimConnect events or states being received! Re-connecting now****

7184047 SimConnect_Open succeeded: proceeding to initialise interface!

7184047 Initialising SimConnect data requests now

7184047 FSUIPC Menu entry added

7186844 Running in "Microsoft Flight Simulator X", Version: 10.0.60905.0 (SimConnect: 2.0.60905.0)

7186844 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\AutoSave Wed 233607.FLT

7186844 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\IFR Schiphol to Tempelhof.PLN

7186891 C:\Documents and Settings\GB\My Documents\Flight Simulator X Files\IFR Schiphol to Tempelhof.PLN

7187125 System time = 23:38:43, FSX time = 05:28:10 (04:28Z)

[Log closed by user request, and continued in new file]

7284125 System time = 23:40:20, FSX time = 05:29:28 (04:29Z)

7284125 *** FSUIPC log file being closed

Memory managed: 4298 Allocs, 4297 Freed

********* FSUIPC Log file closed ***********

[Pete Dowson]

I've been having some problems during my FSX flights

that seem to occur most often after 1+ hours of flight.

What happens is that I lose input to FSX of my stick,

rudder and throttle controls ( Saitek X-45 ).

Are these routed through FSUIPC4, or only assigned and set in FSX?

One symptom that the problem has occured is the

existance of multiple menu entries for FSUIPC4,

usually 2, sometimes 3, where only the last entry

is clickable.

That sounds like the response is so slow from SimConnect that FSUIPC4, as part of its work-arounds for SimConnect problems, is assuming the connection lost and re-connecting.

I can open FSUIPC, make changes, etc

but nothing restores my controls. Re-loading the

flight from the drop-down menu does not cure the

problem nor does selecting a different aircraft.

I must exit flight and FSX and restart.

If this is something that only occurs after some time, the only thing I can think it can be down to is a memory leak from FSX. I have heard mention that there are some, but I guess I've not been flying for long enough in one session to have them affect my system -- it would depend on memory availability and all sorts of other things in any case.

Just to check this, maybe you could do a CTRL_ALT_DEL, Performance tab, and monitor the assorted memory values it shows. Do this near the start of the flight, then half-an-hour into it, then when the problem occurs, and see if any of the values simply keep increasing.

Main memory and video ram are OK. Usually around 1.3GB

out of 2 GB and 330MB out of 512MB being used.

Yes, but when are you checking these figures?

It's obvious that this has something to do with Simconnect

and I have noted your mention of problems related to that

FSX function.

FSUIPC4 (and most other add-ons other than pure aircraft and scenery) is 100% dependent upon SimConnect and, yes, unfortunately at present it does have more than its fair share of problems. Whereas most of the complex work of gathering, processing and setting FS variables via FSUIPC used to be down to me and code within FSUIPC, in FSX (and for the future), Microsoft have taken that responsibility on, and FSUIPC4 is well-behaved, following MS's rules, and using SimConnect for everything.

When it works it will be an excellent solution, but I have already raised many bugs against it and I am pressing for an early fix.

The log indicates that comms with SimConnect were lost

4 times and restored. What is curious is the "menu entry

added" events which are noted 5 times.

The menu entry is added initially, and then it will be after each lost connection. So far, in all the times I've seen a lost connection the menu entry disappears too -- in fact that was the first symptom that alerted folks to this occurrence. Whe FSUIPC4 re-connects it is like starting again, hence the menu addition.

What I saw was

2 FSUIPC menu entries in this case. I'm wondering if

something caused SimConnect to remove the prior entry

instances in 3 cases but not in the last 2, resulting

in the double entry and that this might somehow have

contributed to the loss of controls.

What will likely be hapening is that you are sometimes having a real broken connection, but sometimes it simply that the data from Simconnect has 2-5 second gaps in it (there should be something or other arriving from SimConnect at least once per second -- normally once per visual frame!). These gaps will be interpreted by FSUIPC4 as a broken connection, so it will re-initialise.

I've not seen such gaps before. I can, of course, change my code slighltly to make sure that before re-connecting I send instructions to remove the menu and close the failed connection, but in all previous cases I've seen such calls wouldn't have worked because the connection was deemed closed by Simconnect in any case. I'll do this, but it is only a "tidy-up" action, not a fix for anything at all.

From past experience with WideFS, slow downs in TCP/IP communication after a period seem to usually be associated with memory leaks, and I think that's the first avenue for investigation on your system, as I mentioned earlier.

Anyhow, I'd like to resolve this issue and if you have any

suggestions as to what I might do to assist in tracking down

the culprit, just let me know.

The FSUIPC4 log file merely confirms what you are saying about the time-outs and reconnections, but it doesn't tell me what Simconnect is doing. Could you see if you can get a SimConnect Log made, please. The instructions are in the "FSX Help ..." announcement above. For such a long test the Log will become absolutely massive. ZIP it and send to petedowson@btconnect.com, mentioning how long FSX was running before you noticed the problem -- that will help me get to that part quickly.

Perhaps you could also try actually uninstalling ZoneAlarm, and see if that helps, as a test, please? Although you say FSX isn't "blocked", we have had cases where things did not work correctly in SimConnect until the security programs were uninstalled. If it doesn't make any difference you can re-install it. Otherwise you might consider using WinXP's firewall instead.

You don't mention your anti-virus program at all. Whilst this shouldn't block things, these programs do tend to place hooks into the paths for TCP/IP messages, and this may well be another contributing facor. Again, as a test, it might be a good idea not to just dsable it but to uninstal it temporarily.

P.S. - I originally became aware of the need for local net

access when I shut had my firewall "lock" the access when

I noticed activity when running FSX some time ago. It was

then that I first noticed a loss of controls. I then checked

the net for info and saw your comments on the SimConnect

issue and have not "locked" my firewall since :) So,

I at least know how I CAN cause the problem, if this

might help in doing sometroubleshooting, without waiting

for 1-2 hours in-flight.

Ah, but is that the same problem? In other words, does FSUIPC4 and SimConnect appear to be properly working except for the controls becoming disconnected? I would be most surprised -- the symptom of a blocked access is that FSUIPC4 cannot connerct to SimConnect at all, and logs a failure to Open. In such circumstances you wouldn't normally get a Menu entry at all, although in some cases I've seen the blockage only affect one direction - SimConnect to FSUIPC4, in which case before FSUIPC 4.061 the Menu would appear and then FSUIPC4 would time-out the arrival of data.

By all means show me an FSUIPC4 and SimConnect log of what hapens with the firewall block in place if you think it is exactly the same symptom.

BTW I notice in this Log that the first problem didn't occur until the 120th minute, almost to the dot! Strange timing coincidence I assume?

Also, FSUIPC4 only seems to be allowing 1.3 or so seconds after re-connecting to see the first response. Possibly that's too tight -- I'll make the timing check a little more generous immediately after a retry.

The only other thing I could do in the code is to allow the original response-time check to be extended (i.e. not allow Simconnect to have lapses in its response of more than 1 second). I don't think this is a solution for anything, more another way of finding out what is wrong. Since there are manay things needing updating much more often than every few seconds, I don't think such a change will make it flyable, it would just possibly show us how sssslllloooowwww things are getting. To that end i would add log entries noting the out-of-limits response time but only re-connect when another (parameter-set) timer had expired.

I'm making a note of all these things, but I won't be able to make any changes to help till after Christmas now --i.e. next week some time. As I say, such changes won't fix anything, they may just help show more what is going on.

Then a complete report, including your logs, needs to go to Microsoft. I'd recommend two routes -- I can send direct to the team, you would send via tell_fs@microsoft.com. But there's no rush on either as they won't look at them now till the New Year.

Regards

Pete

[Pete Dowson]

I've been having some problems during my FSX flights

that seem to occur most often after 1+ hours of flight.

Thanks for the FSUIPC4 and SimConnect log files. Oddly enough, even though you say the problem occurred 1 hour into the flight, there are many problems right from the start. In fact it looks like the double FSUIPC menu entry might have been there since the 520th second, or thereabouts -- there are 4 reconnections around the startup!

I find it very very odd that there is then apparently no trouble whatsoever for 3060 seconds (51 minutes). It certainly seems that something is "building up"which brings me again to this:

Main memory and video ram are OK. Usually around 1.3GB

out of 2 GB and 330MB out of 512MB being used.

Yes, but when are you checking these figures?

Did you ever check the memory usage early in the FS session, thaen around the 1 hour into it? That was why I asked when you checked it. To look for memory leakages we need two figures at least.

Anyway, apart from this:

I am embarking on some changes to FSUIPC4 which probably won't help but which may tell us more. In particular I will lengthen the time-outs on re-connection following a re-connection, so that one doesn't precipitate a cascade of them. This may even "recover" from the SimConnect blockage which is certainly occurring, but it cannot avoid it in the first place.

I will also make the reconnection remove the previous menu entry and close the previous connection properly -- in case the only reason for it is a very slow response.

Meanwhile, I note from the logs that you have three distinct SimConnect clients running simultaneously, two of which are very heavy SimConnect users (FSUIPC4 and TractIR). Now I do have one system with both of these on, and get no problems, so I wonder about the third one you have: the one creating an "AddOn Manager X" menu entry, and called "BGLMANX.DLL". Have you tried without that? If not, could you? It appears to be located in your main FSX folder -- just temporarily changing the name will do, before loading FSX.

Look out for the next Interim release of FSUIPC4, in the announcement above. I'll try and get this done by the end of this week (things are a bit slower at present, as my 92-year old father went into hospital before Christmas and I am visiting regularly, which takes several hours per day out of my working time).

Regards

Pete

[Gypsy Baron]

I've been having some problems during my FSX flights

that seem to occur most often after 1+ hours of flight.

Thanks for the FSUIPC4 and SimConnect log files. Oddly enough, even though you say the problem occurred 1 hour into the flight, there are many problems right from the start. In fact it looks like the double FSUIPC menu entry might have been there since the 520th second, or thereabouts -- there are 4 reconnections around the startup!

I was checking the menu frequently during the flight anytime I

noticed a "longer than normal" stutter, just to insure that the

control loss had not occured. I also tweaked thrust settings at

several points during my climbout and allwas well.

I find it very very odd that there is then apparently no trouble whatsoever for 3060 seconds (51 minutes). It certainly seems that something is "building up"which brings me again to this:

Main memory and video ram are OK. Usually around 1.3GB

out of 2 GB and 330MB out of 512MB being used.

Yes, but when are you checking these figures?

I have a small utility called MemStatus 2.50 that sits in my tray and

displays the main and video memory usage. I keep an eye on it and

it did not get above 50% usuage for either resource during this flight.

Did you ever check the memory usage early in the FS session, thaen around the 1 hour into it? That was why I asked when you checked it. To look for memory leakages we need two figures at least.

Anyway, apart from this:

I am embarking on some changes to FSUIPC4 which probably won't help but which may tell us more. In particular I will lengthen the time-outs on re-connection following a re-connection, so that one doesn't precipitate a cascade of them. This may even "recover" from the SimConnect blockage which is certainly occurring, but it cannot avoid it in the first place.

I will also make the reconnection remove the previous menu entry and close the previous connection properly -- in case the only reason for it is a very slow response.

Meanwhile, I note from the logs that you have three distinct SimConnect clients running simultaneously, two of which are very heavy SimConnect users (FSUIPC4 and TractIR). Now I do have one system with both of these on, and get no problems, so I wonder about the third one you have: the one creating an "AddOn Manager X" menu entry, and called "BGLMANX.DLL". Have you tried without that? If not, could you? It appears to be located in your main FSX folder -- just temporarily changing the name will do, before loading FSX.

That's a new one on me.I hadn't noticed that DLL before. I'll

dig around and see where it is and where it came from and

when it "arrived". Then I'll disable it and go flying.

Look out for the next Interim release of FSUIPC4, in the announcement above. I'll try and get this done by the end of this week (things are a bit slower at present, as my 92-year old father went into hospital before Christmas and I am visiting regularly, which takes several hours per day out of my working time).

Regards

Pete

Thanks for taking the time to look into this, Pete, and to make

the changes you have planned. Especially with the holidays and

your father's heath problems. My 85 year old father fell and

broke his hip a couple of weeks before Xmas but was fortunate

enough to be able to be home for Christmas. And too think, at

65, I complain about my aches & pains!

Paul

[Gypsy Baron]

Pete,

After you pointed out that there was a bglmanx.dll using SimConnect

resources , I looked into that addon.

It was added along with the Cloud9 Orlando demo scenery. I remember

now that there was mention of a "manager" that would remain active

after the demo scenery "expired" but I could never locate it to use it.

Well, duh?....it placed a menu item label something like "Addon manager"

or something like that and was the first item in the drop-down menu,

right above the FSUIPC menu item. I must have not noticed that this

was a NEW item and assumed it was just a heading/title for that whole

drop-down menu.

Now to the crux of this...I added the Orlando scenery demo, and thus this

DLL, on December 3rd. Digging back through my logbook, the first instance

of "loss of flight controls" that I noted in comments was on a flight done

on December 4th!

I have now disabled that DLL ( it doesn't appear to be that usefull anyhow )

and will continue to fly and monitor memory resources, system stutters as well as

continue to log SimConnect data. It may vary well be that this DLL was

causing excessive delays in SimConnect data vis-a-vis FSUIPC, resulting

in the multiple menu items and loss of flight controls. In any case, anything that

you are planning to do to prevent or reduce the possibility of multiple

menu item entries would serve well in future as FSX addons become

more plentifull.

I'll keep you abreast of any further discoveries or events related to

this matter.

Thanks,

Paul

[Pete Dowson]

I'll keep you abreast of any further discoveries or events related to

this matter.

Okay. Thank you.

Pete

[Gypsy Baron]

I'll keep you abreast of any further discoveries or events related to

this matter.

Okay. Thank you.

Pete

Here's an update...I just completed a 2.9 hour flight over the same

route that I had to abort on yesterday, EHAM-EVRA.

Different aircraft but the same time of day and similar weather

conditions. Noticed similar FPS throughout the taxi, takeoff and

climb regimes. Same FPS during cruise.

No problems encountered!

So, bglmanx.dll may have been the source of the problems I was

having. Keeping my fingers crossed.

Log file attached, as there was some initial SimConnect data stalled

activity.

Paul

FSUIPC.zip

[Pete Dowson]

No problems encountered!

So, bglmanx.dll may have been the source of the problems I was

having. Keeping my fingers crossed.

Good.

Log file attached, as there was some initial SimConnect data stalled

activity.

Yes. It looks like something is keeping SimConnect from sending me data for several seconds initially. So I re-connect. Then two repeated re-connects occur because I think I don't allow enough time after re-connecting.

Hopefully the changes I am making to the timings will get rid of both of those symptoms.

Thanks,

Pete