FSX crashes with FSUIPC4

[dth]

Hi Peter

I have the same problem (FSX CTD with api.dll error) which only occours when the affinitymask is set to 3 (dual core cpu, vista 64)

as soon as i set the affinitymask to 2 or disable one affinity in task manager, I have no crashes anymore

can it be, that a CTD occurs if fsuipc and simconnect are loaded on different cpu's or get shifted from one to the other?

Thanks a lot for your help and infinite patience

kind regards

Dirk

[Pete Dowson]

H

I have the same problem (FSX CTD with api.dll error) which only occours when the affinitymask is set to 3 (dual core cpu, vista 64)

as soon as i set the affinitymask to 2 or disable one affinity in task manager, I have no crashes anymore

Are you saying this is also only with axis assignments in FSUIPC "direct" to FSUIPC calibration, and not otherwise? Otherwise that sounds like a completely different thing altogether, and more likely related to a problem with your processor or motherboard. What about an affinity mask of 1 (to force the other processor to be used)? Maybe one of your processors is flakey?

can it be, that a CTD occurs if fsuipc and simconnect are loaded on different cpu's or get shifted from one to the other?

Only if the Intel microprogramming which handles the processor switches is broken or the hardware is flakey. I really wouldn't think there's anything in FSX which'll be having anything to do with that. The use of multiple processors in FSX is enabled by multi-threading, but its up to the hardware and microcode behind it to deal with the complications.

Regards

Pete

[dth]

Hi Pete

Everything is set to "direct" but the brakes

and I'm using the MS drivers with my CH Products (yoke, throttle quadrant, pedals, combat stick (axes are switched on/off according to aircraft)) joysticks are switched off in FSX

using the CH Product drivers, the coolie hat is unusable (view turns up and stays there - there seems to be constant signal repeating the value for "view up")

next to FSX I'm running FSCommander, ActiveSkyX, Navigraph and Radar Contact

Airplanes = LVLD 767, Wilco Airbus1 and Wilco B737

CTD normally occures after pushback, beginning to taxi (when I use brakes and rudder)

CPU: Intel E8500 OC@4.03GHz

RAM: 8GB Kingston DDR2-800 OC@850

GPU: Nvidia 9800GTX512 (1920x1200 for FSX) and Nvidia 8800GTS320 (1024x768 for FSC, ASX)

MB: ASUS Maximus Formula (X38)

Temperatures are OK, CTD occures without OC and with all combinations of 4GB RAM as well, latest Nvidia driver fixed msvcert.dll CTD

thanks a lot for your help

kind regards

Dirk

[Pete Dowson]

Everything is set to "direct" but the brakes

Can you save that copy of FSUIPC4.INI (so you can go back to it) and change them all to use the FS controls (you should still find everything you need, unless you are using FSUIPC's separate Reverser axes which don't exist in FSX). Then see if you still get the crash with both processors in use.

CPU: Intel E8500 OC@4.03GHz

RAM: 8GB Kingston DDR2-800 OC@850

GPU: Nvidia 9800GTX512 (1920x1200 for FSX) and Nvidia 8800GTS320 (1024x768 for FSC, ASX)

Phew! That's some system you've got there!

Do you get the crash with affiinity mask set to 1 instead of 2? (Just to eliminate a processor problem as such).

Regards

Pete

[dth]

Hi Pete

I'll try the affinity and the direct vs FS controls over the weekend and report the results

Thanks and regards

Dirk

[Pete Dowson]

I've made a version of FSUIPC4 which avoids using simConnect altogether when you assign axes in FSUIPC for "direct to FSUIPC calibration". I'm hoping that this will stop these crash/hang problems, but since i've never been able to reproduce them I cannot tell.

Download this and try it, please:

http://fsuipc.simflight.com/beta/FSUIPC4289.zip

Sorry, temporarily removed whilst I sort a potential hang out with Mapped axes.

Look out for a link to 4.291 in the next 24 hours.

Please also do the other checks I've mentioned in this thread.

Thanks,

Pete

[Pete Dowson]

I've made a version of FSUIPC4 which avoids using SimConnect altogether when you assign axes in FSUIPC for "direct to FSUIPC calibration". I'm hoping that this will stop these crash/hang problems, but since i've never been able to reproduce them I cannot tell.

Okay. I've modified it so that it still uses SimConnect but just for "mapped" axes (e.g. throttles 2, 3 and 4 when only using one). This otherwise causes a loop with interception followed by re-transmissions ad infinitum.

Download this and try it, please:

http://fsuipc.simflight.com/beta/FSUIPC4291.zip

Please also still do the other checks I've mentioned in this thread.

Thanks,

Pete

[dswo]

Pete, I was on the other thread with assigning multiple controllers per axis. Am still interested in that, and will continue providing feedback there, but I want to add a tiny data point to this thread. On Wednesday, I started having CTDs like the original poster, usually within 15 minutes (again, api.dll listed as culprit).

It didn't occur to me to connect the crashes with FSUIPC, since I'd been running the registered version since June 2, and the unregistered version since FSX was released. Last night, I trimmed some background processes that had crept in (e.g., YouTubeLoader.exe) and also installed the 291 beta you provided on the other thread. Since then, I've flown for about an hour and a half (not all one flight, though) with no CTDs. I'm still a little nervous, but so far, so good.

Like the original poster, I have a menagerie of USB controllers: CH yoke, CH pedals, Sidewinder joystick, Saitek X45 throttle, Belkin Nostromo keypad. Like the original poster, my CTDs began after I started assigning axes directly (on Tuesday of this week). Post hoc ergo propter hoc? I don't know, but my FSX installation was very stable until recently, and the timing fits: CTDs after direct assignment of axes, no CTDs (yet) after installing beta 291 with your new method of axis processing.

[snomhf]

Last night was a little frustrating.

First, I went back to the .ini that uses direct axis modes, set up SimConnect logging and started the famous flight that always failed and got a CDT within two minutes! Great! Boxed it up and sent it to Pete. Pete replied back saying that he had put out a newer version of FSUIPC (4.287, I was using 4.28) and would I repeat the test again with 4.287. Well, when I installed the 4.287 dll, I could not get the darn thing to crash again after that! I had been playing with PollInterval (which did seem to prevent CDTs BTW. Need more testing on that) so my first thought was I had forgotten to remove the variable from the ini. However, it appears that going to 4.287 works for some strange reason. Just for the heck of it, I decided to try the new 4.291 and made two 20 minute flights (the famous one that faithfully crashes) and I was able to complete both of them without incident.

I'm not sure what this all means. I can certainly understand why 4.291 would work but I surely do not understand why 2.87 would also work! I didn't get started on this stuff till late last night and sort of rushed a bit. I'll take a more systematic approach tonight. Stay tuned.

[dswo]

The problem, clearly, is North Carolina. Mark is from Raleigh, Eislinger is from Fayetteville, and I am in Greenville (where, yes, the smoke was pretty bad for three days; I lived in California for 21 years and I've never known anything like it).

[Pete Dowson]

I'm not sure what this all means. I can certainly understand why 4.291 would work but I surely do not understand why 2.87 would also work! I didn't get started on this stuff till late last night and sort of rushed a bit. I'll take a more systematic approach tonight. Stay tuned.

Maybe I can offer an explanation of sorts:

So far, all the evidence, the logs I've seen, and all the investigation over the weeks, are all leading to one conclusion: that it is possible to overload SimConnect to the point where it corrupts data. I suspect that there is a cyclic buffer somewhere which is overfilling and trampling over data.

In all the cases for which I've seen SimConnect logs for so far, the one common happening, a number of seconds before the hang/crash, is a failure like this:

> 200.92873 [ 0, 8175]TransmitClientEvent:ObjectID=0, EventID=65764, dwData=-10402, GroupID=1, Flags=16

< 200.92882 [0] Event: Group=2 EventID=65764 Data=-10402

> 200.92885 [ 0, 8175]

< 200.92886 [0] >>>>> EXCEPTION=2, SendID=8175, Index=0 <<<<< Unrecognized Data Received. [ 0, 8175]

Here you see a command from FSUIPC sending SimConnect a valid Axis event (65764 happens to be "AXIS RUDDER SET", but it could be any axis). The line following is the confirmation from SimConnect that this was okay and accepted.

But the next two lines show rubbish in the buffer that SimConnect is reading from -- the "8175" is supposed to be a unique sequence number, assigned by the SimConnect DLL when it sends the request to FSX (via Named Pipe or TCP/IP), but here it is the SAME ID as the previous good one! And it has no valid data, no actual request, associated with it.

SimConnect (the part in FSX itself) rejects it with error 2, unrecognised data. Okay .... but thereafter things go from bad to worse ultimately hanging FSX.

I have reported all this to Microsoft when I first analysed it, but so far no reply.

Anyway, in one of the increments since FSUIPC 4.28 I added detection of the Error 2 and then automatically turned on lots of extra error logging. This was to try to see if it could possibly be anything i was doing.

I'm guessing now that in your test with 4.287 this extra logging did get turned on, but it was self-defeating in that it slowed the SimConnect traffic up enough to either avoid, or seriously delay, the crash. This is one of the troubles with logging -- Heisenberg's Uncertainty Principle, you can't observe something without changing the outcome! :-(

Anyway, in 4.291, with direct assignments to FSUIPC calibration, I'm avoiding using SimConnect events altogether EXCEPT for mapped axes (that is, for example, Throttles 2 3 and 4 when you pa 1 to 4). If I do what i'm doing for those I get FSX into a very tight loop, as I have to intercept the originals for axes which I'm supposed to be replacing.

Hope this is clear?

Regards

Pete

[snomhf]

Perfectly logical explanation Pete. I was wondering if the extra logging was slowing things down just enough to make it work. I have seen that sort of thing before in other contexts.

So, should I go full bore with 4.291 testing and just forget about earlier versions? Does this mean I should do no more with PollInterval or trying to get you good logs (unless 4.291 fails of course)?

New thought:

It seems to me that if you are right about your "extra logging theory" then if I turn off SimConnect logging in 4.287, I should start seeing CTDs again as it will effectively be just like 4.28 right? I may try that just to try and prove your theory.

[Pete Dowson]

So, should I go full bore with 4.291 testing and just forget about earlier versions? Does this mean I should do no more with PollInterval or trying to get you good logs (unless 4.291 fails of course)?

Yes please, and leave PollInterval to default for now. Thanks!

It seems to me that if you are right about your "extra logging theory" then if I turn off SimConnect logging in 4.287, I should start seeing CTDs again as it will effectively be just like 4.28 right? I may try that just to try and prove your theory.

Well it might be the FSUIPC logging which has the major effect -- it is slowing the feed-in end. And presently, if it sees that Exception 2 from SimConnect, it turns on more of its logging whether you like it or not.

Let's look to the future, with 4.291. I've sent another report to my contacts in Microsoft and will chase the underlying problem separately.

Regards

Pete

[snomhf]

The problem, clearly, is North Carolina. Mark is from Raleigh, Eislinger is from Fayetteville, and I am in Greenville (where, yes, the smoke was pretty bad for three days; I lived in California for 21 years and I've never known anything like it).

No, it's us North Carolinanians that are uncovering all the bugs! :lol:

[snomhf]

Well, I almost hate to say this as I hope I'm not coming back an hour later to retract. (Been there, done that)

But...

I've flown about two hours now with 4.291 and NO CTDs at all! I have double checked that I indeed am running direct, no lurking PollIntervals or anything like that. My assessment at this point is that this problem is solved. Looks like we can point our fingers at SimConnect. WTG Pete!

I'll keep monitoring obviously and report if I have a crash. Certainly I've never gone this long without one before since I have gone direct.

BTW, if you recall, I had started another thread about my controllers not getting sensed correctly and I had to go into FSUIPC after getting in the plane and wiggle them to get them working. Well, I have seen none of that with direct mode either so this appears to have solved both of those problems!

Thank you Pete!

-mark

[Pete Dowson]

... Well, I have seen none of that with direct mode either so this appears to have solved both of those problems!

I'm glad things are going well. Let's hope they stay that way!

Just one more favour, please. In the Simconnect log you provided, whilst I was concentrating on the crash problem, I hadn't examined much else. However, looking at it a little more leisurely I find these repeated at intervals:

> 5.16200 [ 0, 2354]TransmitClientEvent:ObjectID=0, EventID=0, dwData=0, GroupID=1, Flags=16

< 5.16202 [0] >>>>> EXCEPTION=1, SendID=2354, Index=2 <<<<<

> 5.16203 [ 0, 2355]TransmitClientEvent:ObjectID=0, EventID=0, dwData=0, GroupID=1, Flags=16

< 5.16205 [0] >>>>> EXCEPTION=1, SendID=2355, Index=2 <<<<<

Now this is FSUIPC sending events with an invalid (zero) ID to SimConnect. This won't happen with the 4.291 version, but I'm concerned as to why they were being sent in any case, so I need to dig deeper.

To that end I would like to see your FSUIPC4.INI file, please, the one which you used to make the crashes happen (and which you use now I assume). Please ZIP and send to petedowson@btconnect.com.

Thanks!

Pete

[snomhf]

Sure. It's on the way

[Pete Dowson]

Sure. It's on the way

Thanks.

Those errors logged by SimConnect were caused by my calibration "Filter" facility on axes you'd not yet moved (so it had no readings from them) -- probably your aileron and rudder trims. The filter action shouldn't have been operating until at least one value was received.

It did no harm (except put worrying entries in Simconnect's log), but it won't happen in the next release;-)

Thanks again,

Pete

[snomhf]

I've got so many things to move, I don't always remember to move them all! :lol:

Thank you Pete for the great work you've put into this. We really appreciate the support you give us. I know I certainly do.

[Pete Dowson]

Thank you Pete for the great work you've put into this. We really appreciate the support you give us. I know I certainly do.

thanks!

Could yu move on to release 4.294 now, please? There are some other changes (not in the area you've been testing), and I'd like more exposure before I move on to 4.30 as a general release.

Thanks!

Pete

[snomhf]

On the move

[Muas]

Could yu move on to release 4.294 now, please? There are some other changes (not in the area you've been testing), and I'd like more exposure before I move on to 4.30 as a general release.

After some time spent on configuring and recalibrating axes on FSUIPC4291 (and some flying in between) I got one crash, exactly like the ones before.

Also it seems that trim axes are interfering with flaps axes, sometimes I get the flaps dead, and trim axes one side full deflected, all three of them.

All of these when sending axes directly to FSUIPC calibration.

I couldn't replicate either issue of the above, there's no consistency.

I'll try FSUIPC4294 tomorrow and see how it goes.

[snomhf]

4.294 works perfectly for me!

Three hour cross-country and NO problems of any sort. Better than ever actually. The controllers behave themselves better than I've ever seen them. The responsiveness is fantastic!

Thanks again Pete!

[Pete Dowson]

After some time spent on configuring and recalibrating axes on FSUIPC4291 (and some flying in between) I got one crash, exactly like the ones before.

The ones before were preceded, in the SimConnect log, with data corruption in the Axis events being sent.

In 4.291 and after there are no Axis Events being sent for axes sent "Direct to FSUIPC calibration", and there cannot be corruption in data which doesn't exist. So to investigate further, to see if it was Simconnect related, I'd need to see the SimConnect log. It does actually sound as if your crash is not the one others have been suffering at all, and is therefore probably not related to axis assignments at all.

Also it seems that trim axes are interfering with flaps axes, sometimes I get the flaps dead, and trim axes one side full deflected, all three of them.

There's is no way in FSUIPC itself that any such cross-interference could occur. That sounds very much like FSX has picked up its own assignments (again). This can happen quite easily if you ever unplug and re-plug in any controllers. And fully-deflected axes tend to arise from a bad connections, which can look to the Windows drivers like a fully deflected lever. This used to be a common occurrence in the Game Port days.

Regards

Pete

[dth]

Hello Pete

I tested affinity with FSUIPC4.294:

Affinity = 1 >> OK

Affinity = 2 >> OK

Affinity = 3 >> CTD during FMS configuration of Wilco Airbus 321

I'm going to do further testing on Wednesday

Generally it seems that stability is improved

Thank you for your great effort to support your superb program :D

kind regards

Dirk