FSX crashes to desktop (CTD)

[duacar]

When upgraded to version 4.26 did not make a new brake calibration

After I read this topic, i remove the brakes of the domain of FSUIPC and i don't have more problems with crashs FSX

I didn't do more tests

When i reach home I will calibrate the brakes again in the FSUIPC 4.26. Tomorow i write the results

Thanks

Duarte Carvalho

[Pete Dowson]

When upgraded to version 4.26 did not make a new brake calibration

After I read this topic, i remove the brakes of the domain of FSUIPC and i don't have more problems with crashs FSX

But the important thing to note is that the problems appear to be not with the calibration of the brakes, only with the assignment of the axes in FSUIPC4 "direct to" calibration. This is my question. Are you saying that is what you did, or not? Without knowing that your report is not useful I'm afraid.

When i reach home I will calibrate the brakes again in the FSUIPC 4.26. Tomorow i write the results

But version 4.26 does not have the changes I made to, hopefully, fix the problem. It is not the "latest" version -- that is 4.266 in the FSX Downloads Announcements above. There have been 6 increments since 4.26. This is why I stated that your work "latest" doesn't mean anything useful!

I will be uploading 4.269 later today, but that just has new facilities in it rather than any brakes or other such changes.

It may pay you to scan the Announcements from time to time. I do put a Date in the title so that you can tell when something new has occurred.

Regards

Pete

[neorecon]

Pete,

I had a similar situation flying FSX SP2 with the 4.26 FSUIPC. I could regularly get a CTD shortly after I would receive final approach instructions from ATC. I disabled FSUIPC and repeated the flight and did not get any CTD.

Tonight I downloaded your updated .dll and re-enabled FSUIPC. This time I did not get a CTD.

It is late now, so I'll do a few more test flights tomorrow night after work to verify, but so far it seems like it works, because I could ALWAYS get the CTD on final approach.

I will say however that thanks to your auto-save feature I was always able to re-load the flight and continue through my landing.

Jason

[duacar]

Hi, again

Sorry if i don't put all the information- I have FSUIPC 4.266

(I have crashs in FSX - Axis assign in FSUIPC(previous version), Direct to FSUIPC calibration - FSX disabled JoyStick.

I Still have crashs after upgrade to 4.266 - Don't make any calibration or modification in the controls

Like i told before remove all the assignments for brakes in FSUIPC (4.266) Enabled JoyStick FSX- No crashs)

After re-calibrate the Brakes - Axis assign in FSUIPC, Direct to FSUIPC (4.266) calibration

I make one flight, about 2 hours:

FSX Enabled JoyStick (I delete all axes in FSX controls) - In final have a crash

So i make two flights, about 30 minutes each one:

FSX disabled JoyStick - No crashes

One question: Its wise after a upgrade of FSUIPC - calibrate all axes?

Tonight i will upgrade FSPUIC to 4.269

I will make some flights, and i informed if i have a crash

Thank you (Sorry for all the work, and sorry for my bad inglish)

[Pete Dowson]

I Still have crashs after upgrade to 4.266

Damn. I thought it might be related to having too many successive brake events being sent to FSX. I cut that right down, but it seems not to be the answer.

I cannot reproduce the problems here but maybe I just don't try for long enough. From what you say, though, it isn't crashing when you are USING the brakes at all, just flying? Or will the brakes be occasionally engaging whilst you are using the rudders? Are you avoiding toe brake action when using rudder? Do you have a good dead zone calibrated?

One question: Its wise after a upgrade of FSUIPC - calibrate all axes?

No. That won't make any difference at all. FSUIPC's menthods of calibrating haven't changed in many years.

Tonight i will upgrade FSPUIC to 4.269

I don't think that will be different in this regard from 4.266.

I am really puzzled by this one.

Regards

Pete

[neorecon]

Pete,

Here was my setup:

FSX SP2 running FSUIPC 4.26 from the main website. I was flying Wilco's CRJ (with the upate for FSX) I was also running AI Smooth, FTG ACARS, and ASX, and xPax on a second PC. I would always crash shortly after getting OK from ATC for final approach.

1. I turned off all add-on's connecting from second PC (ASX, xPax, ACARS, AI Smooth) Still would CTD

2. I turned off FSUIPC and allowed FSX to manage all joysticks. No CTD

3. I updated the .dll to the latest one provided here in the forums and re-enabled FSUIPC. No CTD

4. Tonight I will turn on the Second PC to see if that will cause any issues.

At no time was I breaking, although I wonder if there are more commands or the like that are being processed during a final approach compared to TO and Cruise?

[Pete Dowson]

I would always crash shortly after getting OK from ATC for final approach.

Right, so certainly not deliberately using the toe brakes! ;-)

1. I turned off all add-on's connecting from second PC (ASX, xPax, ACARS, AI Smooth) Still would CTD

2. I turned off FSUIPC and allowed FSX to manage all joysticks. No CTD

3. I updated the .dll to the latest one provided here in the forums and re-enabled FSUIPC. No CTD

No CTD with the latest updates? That's different from duacar's reports.

4. Tonight I will turn on the Second PC to see if that will cause any issues.

Hmm. Seems it must be down to some weird combination of events, because there's only two reports and I know for sure that a lot of folks calibrate toe brakes through FSUIPC4 -- myself included!

At no time was I breaking, although I wonder if there are more commands or the like that are being processed during a final approach compared to TO and Cruise?

If the brake axes aren't being used at the time it is hard to see how they become involved, unless some early problem, before takeoff, actually caused some delayed-action corruption.

I've traced through all the code paths which are invoked with directly assigned toe brakes, and it is all innocuous stuff. So I remain completely puzzled I'm afraid. I really have no idea how to obtain more information to help -- normally it is obvious that something ought to be logged or traced, but this time, nothing. :-(

I have found a typo in the code which affects a few FSUIPC offset read-outs. I can't see how any of them would have any bearing on this problem, but it may be worth me sending you and duacar another test version, just in case.

Later ...

Regards

Pete

[neorecon]

I used to work in the software development industry, so I feel your pain. I'll see what I can do to reproduce the same situation.

[John Veldthuis]

I to am getting a lot of CTD's but cant pin it down to anything. I use FSUIPC for my brakes because FSX does not handle them properly and after using them leaves values that cause the PMDG 744X autobrakes/spoilers not to work. My CTD occurs at various times. Once just after landing on a 4 hour flight and just about to turn off the runway, next time just about to apply full power for a takeoff, another time 10 minutes into a climb out of an airport. This list goes on. I am not going to say it is FSUIPC or not but it has just started happening recently. May try and find an earlier version to see if I can stop it.

Cant take my brakes out of FSUIPC for the above reason.

[Pete Dowson]

Cant take my brakes out of FSUIPC for the above reason.

You can assign in FSUIPC and calibrate in FSUIPC without using the "direct to FSUIPC calibration" option in the assignments tab -- so far it is only that route which seems to be causing any grief. Though it isn't that alone -- something else is interacting with it. Many folks use the same method (i do, for one) and never have any crashes, so it is down to some odd combination of factors.

As well as using other assignment/calibration methods you could try my latest update. I've fixed an entirely unrelated bug, but you never know. Download this: http://fsuipc.simflight.com/beta/FSUIPC4271.zip

[NOTE].

Regards

Pete

[Pete Dowson]

I used to work in the software development industry, so I feel your pain. I'll see what I can do to reproduce the same situation.

Thanks. Please also try http://fsuipc.simflight.com/beta/FSUIPC4271.zip . I've fixed an entirely separate problem which I cannot see having any affect in this, but you never know.

[NOTE]

Regards

Pete

[Pete Dowson]

Sorry if i don't put all the information- I have FSUIPC 4.266

Please now try http://fsuipc.simflight.com/beta/FSUIPC4271.zip . I've fixed an entirely separate problem which I cannot see having any affect in this, but you never know.

[NOTE].

Regards

Pete

[neorecon]

Doing some more research on this.

What video cards is everyone here that has this problem using? What OS?

I'm running Vista Home Premium 32Bit w/ an Nvidia 8800GTS (174.74 Drivers)

From browsing around this could be a video driver issue too.. so I'm going to try a few different scenarios and see if I can't narrow down what causes the crash. I did get it to crash again but it was shortly after takeoff this time, so there seems to be no pattern whatsoever.

I'll let you know if I find anything out. I did apply your latest .dll update.

[neorecon]

Well I'm not sure what to tell you. I updated my video drivers and I changed how the rudder pedals were configured in FSUIPC...Instead of direct (managed by FSUIPC) I changed them to send direct to FS.

So far I've finished one short hop (1hr) and am now in the middle of a return flight with no problems. Tomorrow, I'll try reconfiguring my rudder pedals back to the usual way in FSUIPC and see what happens.

[Pete Dowson]

I'll let you know if I find anything out. I did apply your latest .dll update.

Which one? The 4.271 I provided a link to in this thread?

AAARRGGHH! I just noticed, I provided the wrong link! Ouch. Sorry. Use this:

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

And please, please, please, never ever just use the term "latest". It is absolutely meaningless. Please always give the version number. That's why I update those things, so I know what you are referring to!

Pete

[rocketman3]

Pete,

I've been using 4.2.6.6 with the calibration approach you recommended (creating a null zone for the brakes) and it seems to be more stable. I've had the odd crash or two but that may be from something else. I'm running most of my add-ons now as well. I'll run with this configuration for a while and see how it goes.

Regards,

Glenn

[Pete Dowson]

I've been using 4.2.6.6 with the calibration approach you recommended (creating a null zone for the brakes) and it seems to be more stable. I've had the odd crash or two but that may be from something else. I'm running most of my add-ons now as well. I'll run with this configuration for a while and see how it goes.

Okay, but I'd rather you use 4.272, now available in the Downloads announcement. The fixes other things, probably totally unrelated.

Pete

[neorecon]

Sorry about the 'latest' comment. I'll re-download tonight when I get home and try again. If everything continues to work well after a few flights I will revert back to having FSUIPC manage the rudder/breaks and see what happens.

[neorecon]

OK I thought everything was working ok until I did a longer flight from MSP to SLC.

I had simconnect set to log and here was the place where errors started showing up:

> 646.47948 [128, 11683]
< 646.47949 [128] >>>>>  EXCEPTION=2, SendID=11683, Index=0  <<<<<  Unrecognized Data Received. [128, 11683]
> 646.47953 [128, 11684]RequestSystemState:RequestID=1, szState="Sim"
< 646.48651 [128] ObjectData: RequestID=14  DefineID=14  dwSize=292
< 646.48654 [128] ObjectData: RequestID=24  DefineID=24  dwSize=96
< 646.48659 [128] ObjectData: RequestID=14  DefineID=14  dwSize=292
< 646.48662 [128] ObjectData: RequestID=24  DefineID=24  dwSize=96
< 646.48667 [128] ObjectData: RequestID=14  DefineID=14  dwSize=292
< 646.48669 [128] ObjectData: RequestID=24  DefineID=24  dwSize=96
< 646.48675 [128] ObjectData: RequestID=14  DefineID=14  dwSize=292
< 646.48677 [128] ObjectData: RequestID=24  DefineID=24  dwSize=96
< 646.48737 [128] EventFrame: 0  10.296438
< 646.50543 [128] ObjectData: RequestID=9  DefineID=9  dwSize=72
< 646.50557 [128] ObjectData: RequestID=7  DefineID=7  dwSize=48
< 646.50559 [128] ObjectData: RequestID=10  DefineID=10  dwSize=1504
> 646.56970 [128, 1778608580]
< 646.56974 [128] >>>>>  EXCEPTION=5, SendID=1778608580, Index=61259  <<<<> 646.56976 [128, 1800271806]
< 646.56977 [128] >>>>>  EXCEPTION=5, SendID=1800271806, Index=61259  <<<<> 646.56979 [128, 35652893]
< 646.56980 [128] >>>>>  EXCEPTION=5, SendID=35652893, Index=61259  <<<<

Does that make any sense?  From what I've read it looks to mean that I have something that is trying to use a different version of Simconnect, or was writen for a different version with my PC.  ASX and FTGACARS are both listed as SP2 compatible.  Both of my machines have 3 installations of simconnect (as I read you should have them installed this way)  Is that incorrect?
Either way I'm not sure why this suddenly happened.  I flew two flights earlier today KMSP-KDLH and back, and then KMSP-KEAU without any problems.  Very odd to say the least.
This was using your 4.27x version of the dll and the rudder/brake pedals mapped straight through to FS (not the Direct FSUIPC optioin)
Also had this in the fsuipc log file:
[code]   16115 Broadcasting service every 1000 mSecs
  1435833 **** ERROR! Sumcheck or length fails on received socket 9168 block, len=96 (time=11941150)

[Pete Dowson]

I had simconnect set to log and here was the place where errors started showing up

Those errors are most certainly down to corruption occurring between the SimConnect DLL and FSX.

Does that make any sense? From what I've read it looks to mean that I have something that is trying to use a different version of Simconnect, or was writen for a different version with my PC.

No, because the version data reported in the errors is rubbish. The whole sequence is most definitely indicative of a completely corrupted set of data in the pipeline between SimConnect.DLL and FSX itslef.

I have no idea how that can arise. It is using a Windows facility called "Named Pipes", which is merely a way of using shared memory between processes. This has got to be down either to a faulty memory module (possibly overheating memory?), or a bug in either Windows or SimConnect. There's real;ly no way anything in any application add-on can be responsible for these errors.

You could try forcing Simconnect back to using TCP/IP, just as an experiment. It is slower, a lot less efficient, and may slow things down a bit. Of course it still uses memory buffers, but not the same one all the time -- it'll keep allocating and freeing them. To force SimConnect to use TCP/IP you need to put a SimConnect.XML file into the same folder as your FSX.CFG file.

See below. You don't need the Blue bit if you aren't using SimConnect over a Network. If you already have this file, to run, say, ASX, from a Networked PC, just add / chage the RED bits:

SimConnect

SimConnect.xml

False

False

IPv4

global

LEFT

500

64

4096

True

False

IPv4

local

True

Pipe

local

Ah, I see that you do use SimConnect over a Network, so probably all of the above file is relevant -- check the corts and so on in the version you are using. All I'm doing is changing the usual local "Auto" protocol to "IPv4", and adding a complete new entry, in red above, to disable the local "Pipe" protocol.

Also had this in the fsuipc log file:

   16115 Broadcasting service every 1000 mSecs
  1435833 **** ERROR! Sumcheck or length fails on received socket 9168 block, len=96 (time=11941150)

That is from the WideServer log -- FSUIPC never logs any such thing! And it's not related, but a glitch on your network. The odd one now and then probably doesn't matter, though on a truly healthy network you should never seen any such errors.

Regards

Pete

[neorecon]

Thanks Pete...

I'm running an Orthos Stress test on my PC today testing out the ram and the CPU. Since this seems to only happen when I'm simming for 2+ hours I'm going to run the stress test for 3-4 and we'll see what happens.

Also, do you suggest using simconnect via Named Pipes? I'm in the IT industry and I had always figured that TCP would be a better protocol to utilize. But based on your comments, it appears that I may wrong.

In my Simconnect I've been utilizing IPv4 strictly, but may reconsider if you think it may help.

[Pete Dowson]

Also, do you suggest using simconnect via Named Pipes? I'm in the IT industry and I had always figured that TCP would be a better protocol to utilize. But based on your comments, it appears that I may wrong.

For the local connection, between programs running on the same PC as FSX, Named Pipes should be much more efficient as they are simply implemented via shared memory, much like FSUIPC's own interface with its clients.

For a Networked connection it make little to no difference as pipes are transported using TCP/IP protocols in any case.

It worries me a little that so much TCP/IP data exchange is by UDP which is basically unchecked and un-recovered on error, unlike TCP. In a perfect world UDP would be preferable as it is faster without the red tape. But ...

In my Simconnect I've been utilizing IPv4 strictly, but may reconsider if you think it may help.

By default SimConnect SP2 or accel uses Pipes locally when you set "Auto" in the XML file (or don't provide an XML file). Prior to SP2/Accel pipes weren't an option.

Regards

Pete

[neorecon]

So would you suggest just having the SP2 SimConnect installed then and not install the SP1A and RTM versions? I've read conflicting information on this whole topic online.

[Pete Dowson]

So would you suggest just having the SP2 SimConnect installed then and not install the SP1A and RTM versions? I've read conflicting information on this whole topic online.

For the FSX PC you should have all three versions of SimConnect installed, as different SimConnect client programs will need different ones. For DLLs and Gauges using SimConnect, like FSUIPC4, the RTM version is usually needed (even if they then use a later one), as it is the one which loads them. The same would apply to any EXE's you have loading automatically (via the EXE.XML file).

For Networked PCs you need whichever versions of SimConnect may be needed by the applications you run which use them.

Having multiple versions installed does no harm. They install into the Windows "SideBySide" library system which allows different versions of the same library to be used by different programs, according to their expectations and needs.

Pete

[neorecon]

Sounds good.

I think I may have overloaded the TCP side of things as I had removed the 'pipes' line from my simconnect.xml and was using TCP exclusively for both local and global connections. I will reconfigure from scratch and see what happens.

I was rather frustrated by everything yesterday so I'm starting with a fresh install of FSX and FSUIPC and will slowly add third party add-on's and test to ensure that they will work correctly... Looks to be a fun weekend indeed.

Thanks for your assistance with this issue and I will post back with my results. I'm guessing it was probably my elimination of the pipes configuration that could have caused the errors, especially if the communications were not as efficient through TCP. I'm assuming that there is alot of data that gets passed through as when I had the logging on for Simconnect, my 2 hour flight generated a rather large log file.