FSX crashes with FSUIPC4

[snomhf]

I have recently begun to get crashes with FSX (for the last few weeks) during flight. It's the type of crash where you are prompted to send an error report off to MS. I'm pretty sure I've isolated it to FSUIPC. I have collected the error report as well as the FSUIPC.ini and log files here:

http://snomhf.exofire.net/data/FSUPIC4errorrpt.zip

Here is what I have done to isolate this problem:

Completely removed FSX from my system including the FSX.cfg file and the entire tree under Documents And Settings. Also including was the only other module I use (SIMCharts) and the Acceleration pack.

1. Installed only FSX up through SP2 (rather than Acceleration) as well as FSUIPC4 with the ini that I had been using all along. I did not install the Acceleration pack or SIMCharts. As best as I can tell, I have a "stock" install at SP2 at this point except for FSUIPC. The crashes still occur.

2. Tried using a default FSUIPC4 with the setup from (1). Crashes still occur. I tried both FSUIPC 4.20 and 4.28.

3. Uninstalled FSUIPC4. Tried deleting my FSX.cfg file and allowing FSX to create a new one. Ran for a couple of hours with no crashes. I then put my "normal" FSX.cfg file in place but turned on controllers inside FSX since I had FSUIPC uninstalled. Ran a couple more hours with no crashes at all.

4. Installed FSUIPC4 with the basic FSX.cfg, turned off controllers in FSX and the crashes returned.

5. Tried settings "Normal Settings" in FSUIPC4 with no positive results.

I have obviously changed something that is causing this as I have been running with no problems until a couple of weeks ago. I just can't figure out what has been changed.

Right now, the only thing that seems to work is to run without FSUIPC. I can run both Acceleration Pack and SIMCharts without incident.

Thanks for any advice/help in this matter.

-mark

[Pete Dowson]

I have recently begun to get crashes with FSX (for the last few weeks) during flight. It's the type of crash where you are prompted to send an error report off to MS. I'm pretty sure I've isolated it to FSUIPC.

FSUIPC cannot easily itself cause FSX to crash -- all cases so far have been either due to the actions of programs using FSUIPC or to bad FSX data which just happens to be accessed more thoroughly or frequently when FSUIPC is running. The prime instance of the latter are the weather files associated with flights which are notorious ofr crashing FS when corrupted.

I have collected the error report as well as the FSUIPC.ini and log files here:

This shows FSX crashing immediately on loading the Flight

c:\documents and settings\mhf\my documents\flight simulator x files\Chap_10_Lost_and_found.FLT

Previous to that it had loaded three flights quite happily.

Completely removed FSX from my system including the FSX.cfg file and the entire tree under Documents And Settings. Also including was the only other module I use (SIMCharts) and the Acceleration pack.

When you say "entire tree", can you explain, please. Obviously you cannot mean exactly that, as that contains most of your system information, not just flight sim stuff.

In particular, it is important to note that for a clean install there are at least THREE FSX folders needing removing in the Systems area:

1. The "My Documents/Flight Simulator X Files" part you presumably meant.

2. Your "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX" folder, where your FSX CFG and other vital files are kept

3. Similarly the "C:\Documents and Settings\All Users\Application Data\Microsoft\FSX" folder, where the scenery configuration goes.

Also, because SimConnect is a "side-by-side" system installation, is doesn't get uninstalled. I think the only way to be sure a corrupted Siconnect is replaced is to actually delete its folders -- as described in the FSX Help announcement above.

1. Installed only FSX up through SP2 (rather than Acceleration) as well as FSUIPC4 with the ini that I had been using all along. I did not install the Acceleration pack or SIMCharts. As best as I can tell, I have a "stock" install at SP2 at this point except for FSUIPC. The crashes still occur.

2. Tried using a default FSUIPC4 with the setup from (1). Crashes still occur. I tried both FSUIPC 4.20 and 4.28.

When you uninstalled FSX did you also delete any folders left behind? With the Modules folder having been added by FSUIPC's installer, the FSX uninstaller won't remove it, so the re-install would not have given you a "default" FSUIPC. You'd need to delete the folder entirely then rerun FSUIPC's installer.

Thanks for any advice/help in this matter.

There's really no other information in the stuff you've provided to indicate what might be happening. Something is either corrupt on disk, or is getting corrupt in memory. Things like a memory fault can give results like this, so after thoroughly eliminating possible software suspects it may be time to look at the hardware. The fact that it all used to be okay then suddenly started doing this consistently does smack of something getting broken or failing.

Regards

Pete

[snomhf]

Thank you Pete for your very thorough reply.

FSUIPC cannot easily itself cause FSX to crash -- all cases so far have been either due to the actions of programs using FSUIPC or to bad FSX data which just happens to be accessed more thoroughly or frequently when FSUIPC is running. The prime instance of the latter are the weather files associated with flights which are notorious ofr crashing FS when corrupted.

This shows FSX crashing immediately on loading the Flight

c:\documents and settings\mhf\my documents\flight simulator x files\Chap_10_Lost_and_found.FLT

Previous to that it had loaded three flights quite happily.

Interesting, I was certain I saved off the correct report. I must have made a mistake on that somehow. It usually takes 15-20 minutes of flight for this to happen.

When you say "entire tree", can you explain, please. Obviously you cannot mean exactly that, as that contains most of your system information, not just flight sim stuff.

Sorry about that. I mean to say the tree "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX"

In fact, here is the process I followed to delete FSX: (Isaved off my FSX.CFG and FSUIPC4.INI first)

1. Uninstalled FSX via "Add and Remove Programs"

2. Deleted "C:\Program Files\Microsoft Games\Flight Simulator X"

3. Deleted "C:\Documents and Settings\mhf\Application Data\Microsoft\FSX"

4. Deleted "My Documents/Flight Simulator X Files"

I DID NOT delete "C:\Documents and Settings\All Users\Application Data\Microsoft\FSX" (didn't think about that)

NOR SimConnect (wasn't aware of it).

I am going to do this all again making sure I get the "All Users" and SimConnect parts.

There's really no other information in the stuff you've provided to indicate what might be happening. Something is either corrupt on disk, or is getting corrupt in memory. Things like a memory fault can give results like this, so after thoroughly eliminating possible software suspects it may be time to look at the hardware. The fact that it all used to be okay then suddenly started doing this consistently does smack of something getting broken or failing.

It has gotten very hot around here (over 100 deg F during the day) and I have wondered if perhaps that is a factor although I am leaving the machine powered off when I'm not using it, use plenty of ventilation in that room, and monitor my temps pretty carefully. My CPU/GPU/Bridge temps don't show any higher than they did during the winter months when all was working well. I do (and have for quite a while now) have my CPU and memory overclocked a bit. It sounds like I should put the machine back to a perfectly stock state and try this all again and see if it is overclocking that is causing this. I have gone the extra mile with case fans and coolers for my CPU, North/South Bridge coolers, etc. and feel pretty confident that my temps are not high. The other game I play is Aces High which pushes the hardware pretty hard and I have never had a single freeze or CTD with it. I realize that's not necessarily "apples to apples."

Thank you again for giving this the attention that you have.

[Pete Dowson]

... The other game I play is Aces High which pushes the hardware pretty hard and I have never had a single freeze or CTD with it. I realize that's not necessarily "apples to apples."

Two possibly relevant stories to relate. First, one which happened to me this week:

I'd updated a PC with new video Card, DX10 capable, installed vista 64, and was about to upgrade memory from 2Gb to 4Gb. Between each step I was re-testing FSX + FSUIPC4 + my cockpit drivers (working through Axis assignment & Calibration in FSUIPC4). I suddenly noticed, on Tuesday this week, that on one particular Joystick Calibrations page, one of the normal "min" Set buttons was always disabled and the two right-most axes couldn't be calibrated because the main Set buttons did nothing.

Now nowhere in my code do I enable/disable Min/Centre/Max "Set" buttons, I only ever change whether they are visible or not. And I've no idea what the non-operative Set buttons were trying to do. So it was a struggle. Annoyingly, with a Debug version it didn't happen, nor with a previous version.

Thursday after wasting nearly three days looking for an impossible software bug, I gave up. I decided it was impossible for these things to happen UNLESS some pixie was actually change values (bits) inside memory ..... Clunk! Memory!

Luckily I had another pair of 1 Gb sticks (as I said, I was about to upgrade from 2 Gb to 4 Gb), so I swapped them over. Bingo! no more weird inexplicable problems!

The second story is actually more elongated, a long thread here relating to a crash which was occurring in FSX on longer flights. It seems it all started when wind smoothing was added to FSUIPC, so this was under suspicion. All sorts of things were tried, till, finally, the fault went "solid" and turned out to be a memory problem also -- new memory chips and all was well.

All I'm trying to point out here is that when things worked once and then don't for no apparent reason, it is not always something you've done, and not always a software bug. With two recent incidents both costing a lot of time and both down to memory chip problems, I am beginning to wish PC memory never started leaving off the Parity checking. My new PC, just arrived today, has parity checked memory. I realise it might be a bit slower but in the long term it might save me a lot of bother! ;-)

Regards

Pete

[snomhf]

Sounds like its time for me to slip in the ole Memtest86 cd tonight and let her cook all night.

Thanks Pete. What you're saying sounds very logical. I have been a bit suspicious of this rather cheap Corsair memory I put in this machine anyway. Maybe I should spring for some G.Skill PI that I see on sale at Newegg.

[Eislinger]

Its probably the smoke coming in from the east during the past two days from the fires !

[snomhf]

Its probably the smoke coming in from the east during the past two days from the fires !

You are right about that! It looked like a movie set of London yesterday morning around here. It's amazing that we got smoke like that from wild-fires 100 miles away! I feel very bad for those folks in eastern North Carolina.

[snomhf]

Well, I believe I've eliminated memory and overclocking as the problem. I'm going to borrow some G.Skill PI from a friend of mine next week and check it just to be sure. Anyway, here is what I've done:

1. I ran Memtest86 for almost three hours and no errors at all turned up. You would certainly think that ought to do it. I have run it all night (8-9 hours) before but I would think three hours ought to do it since this crash is so reproducible. I'm going to start up Memtest before I go to bed tonight and let it cook all night.

2. I set all my clock speeds and overvoltage back to stock settings. FSX still crashes.

3. I have four sticks of Corsair XMS DDR2-800. I have tried pulling half of it and get failures with each set. That means if there are errors in the memory, they have to be in at least two sticks. I would think that unlikely. I did not try the six combinations of possibilities. :)

One thing is for sure, if I delete FSUIPC (I simply rename the "modules" directory and create an empty one), I have YET to get a crash under any of these circumstances. As soon as I put FSUIPC back in, it crashes almost every time.

I'm running out of things to try. :(

If my logic is faulty, I certainly would appreciate being set straight.

Thank you!

-mark

[John Veldthuis]

Sounds like its time for me to slip in the ole Memtest86 cd tonight and let her cook all night.

That is not a sure test either. My memory passed the tests time after time with no errors being thrown up. It only made itself apparent when the one of the 1GB sticks failed completed (still have not worked out which one it is because they are now on my desk). I even did the tests while it was crashing just before it failed completely and no issue was found.

[snomhf]

My memory just passed ten hours of stress test with Memtest86.

[Pete Dowson]

My memory just passed ten hours of stress test with Memtest86.

I don't really think that's very relevant. I only found out by swapping memory chips. Don't forget, there's no parity checking on the current DDR memory in most motherboards. Stress testing doesn't properly test long-term retention nor pattern interference. The best way always is to try alternatives.

Pete

[snomhf]

I don't really think that's very relevant...

Pete

I understand. I just figured I'd do it while waiting to borrow memory.

[John Veldthuis]

My memory just passed ten hours of stress test with Memtest86.

Mine passed 20 hours but it was still faulty just as I said. No indication (except for the crashes in FSX) until it failed completely. Since the new memory not one crash at all.

[snomhf]

I figured it out!! :D

I'm actually feeling kinda stupid over this. About three weeks ago (interestingly enough about the time this problem began [exactly if I were to be honest] ) I read a help document on this forum describing how to set up CH gear with FSUIPC. I decided to read it just to see if there was any little tid-bit I was missing since my stuff (except for the annoying axis "non-wakeup" issue) was working pretty good. The guy was describing assigning your axes and he has you select:

O Send direct to FSUIPC Calibration

Well, I had it set this way:

O Send to FS as normal axis

for ALL my axes. I proceeded to delete all my axis assignments and set them to "Send direct to FSUIPC Calibration" so as to match what he was suggesting. I was mainly curious to see if it would help my controllers to "wakeup" better when I started a flight. Low and behold, it seemed to help quite a bit. Maybe it was just imagination but it really seemed better. The unfortunate part in all this was I didn't fly very much for the week that followed and I sort of forgot that I had made this change. It was after that that I began to see all these crashes I've described in this thread.

Now, you would think that a guy who has been methodically eliminating ALL possibilities (re-installing FSX), deleting other add-ons, even un-overclocking, sweat testing and swapping around memory, CHDSK, De-frag, etc., etc. would think to try "Send to FS as normal axis" on my axis assignments (like I originally had done) but somehow I never thought to do that....

Until last night (after days of ripping my computer apart).

Well, that fixed it! I have made three flights (total of about four hours) last night and today and not a single crash! There is NO way I could have gone fifteen minutes with "Send direct to FSUIPC Calibration" select for my axes.

I never have been very clear on what these selections are but I sure won't forget which one to use from now on.

Thanks for all who helped me; especially for the kind advice of Pete. Sorry to have bother you so much about this. I really should have been able to figure it out without making a public spectacle.

Regards,

-mark

[Pete Dowson]

I proceeded to delete all my axis assignments and set them to "Send direct to FSUIPC Calibration" so as to match what he was suggesting. It was after that that I began to see all these crashes I've described in this thread.... would think to try "Send to FS as normal axis" on my axis assignments (like I originally had done) but somehow I never thought to do that....Until last night (after days of ripping my computer apart).

Well, that fixed it! I have made three flights (total of about four hours) last night and today and not a single crash! There is NO way I could have gone fifteen minutes with "Send direct to FSUIPC Calibration" select for my axes.

Okay. That's interesting, but I still don't understand it.

I've always had all my axes (not from CH equipment though) sent "direct". It is more efficient, if you are calibrating in FSUIPC, because the other method involves three times as many messages flying about between FSUIPC and SimConnect -- one lot to send the axis values to FS, then the same stuff being sent from FS to FSUIPC for calibration, then back from FSUIPC to FS after calibration.

With "send direct", your axis values are calibrated then sent to FS, by-passing the circuitous route. One set of transfers, so it should be simpler, less error prone, and three times more efficient! In theory.

So, now I have to find out what there is about that which could possibly make a system crash.

Pete

[snomhf]

Pete,

I would be happy to be a guinea pig for any testing you'd like me to do. As I've said, I can reproduce this problem like clock-work within fifteen minutes. I have, to the best of my ability, eliminated hardware issues, faulty installation, etc. from the equation. I still have the FSUIPC.ini that fails on hand so it's a very quick swap to do it.

I have a montage of equipment so to say I have "CH equipment" is not getting the true sense of it. My joystick has a Logitech Wingman board in it that controls the X&Y axes and a CH FighterStick board that controls my rudder and aileron trims. I have a CH Pro Throttle with Leo Bodnar's BU0826 board in it that drives my elevator trim, prop RPM and mixture axes. The only unmodified controllers I have are my CH Pro Pedals and CH Throttle Quad. You can see a picture of my gear if you're interested here: http://snomhf.exofire.net. There are also articles about my gear and other mods I do there if you're interested in any of that.

I'm glad you explained about "send direct." I sure can tell the difference with respect to having to move all my controls while the flight is loading else my plane will veer all over the place because the controls were not sensed correctly. I don't recall that problem ever occurring with "direct." I would love to go back to "direct" if it wouldn't crash.

Anyway, it's nice to be back up and running. I'm still going to try this G.Skill Pi memory as a test just to see if it makes any difference. I guess it's possible that I still have a memory problem that only "send direct" can find.

This has been an education and actually sort of fun. One thing is for sure, I have a nice clean install of FSX now and thoroughly cleaned up and tested computer. :)

-mark

[Muas]

Hi.

I'm going through something similar - except I don't plan to tear my PC apart (I hope :? )

I'm still a bit knew to FSUIPC, installed it about 3 weeks, and lately I've been suffering from FSX hangs, followed by the fatal FS error mesage and prompt to address it to MS. I mean, lately, more and more often, and now it happens everytime I run whatever mission.

Lets review what I did:

1) Installed FSUIPC and start configuring it. Cool program.

2) I started configuring it storing settings by aircraft. General assignmets for prop/turboprops; specific assignments for jets.

3) I noticed a hang once in a while. Didn't bother with it too much, there was no consistency - I couldn't recreate them, so I thought "if this is real, it will reveal itself sooner or later, too soon to trace it yet".

4) I continued configuring aircraft, this time assingning specific flap settings for each airliner, and yes, I was using the "Send to FSUIPC calibration" option, more and more, I just thought it was the best way to do it. Hangs become consistent. "Its time to sort this out".

5) I just made one test: disabled the FSUIPC.dll manualy. I didn't uninstall anything - just disabled FSUIPC from running on FSX load up.

6) FSX run ok, no more hangs. Enabled FSUIPC to load again. Hangs about five minutes from mission start, everytime. Disabled again - no hangs.

I'm having 3 days out of town work, and was wondering what to do next - sometimes its better do nothing and sleep a bit on the subject than start messing around without a clue. Then I made my mind about my next step: I'd clean up the FSUIPC ini file and start configuring axes again from the start. I was sure FSUIPC was pushing hard on something my rig couldn't cope with. Then I started reading this thread. In fact I started to read it earlier but when I reach the memory testing part, I thought "forget it, I aint got time to that, maybe I'll quit on FSUIPC instead". But I decided to read further on a few days later, till I reached the axes assignment option, then I thought "of course, my hangs grew up as I was using that option more and more, so that must be it!".

So, I'll be back to my PC before the weekend. I'll disable that "send to FSUIPC calibration" and start testing from there.

I'll report back then. Thanks for continuing this discussion, it probably saved some people lot of trouble (including me I guess).

[Pete Dowson]

Hangs about five minutes from mission start, everytime. Disabled again - no hangs.

These are hangs, not crashes like before? And only in missions, not free flight?

I am trying to figure out some way of getting to the bottom of this, as I've been using direct assignment for everything since FSX started and cannot reproduce any problems. And I know the direct method is used by a lot of folks, so there must be something more to it than just that. some other factor.

Pete

[Muas]

To me, it is allways the same situation: the image freezes with the mouse pointer turning to hour-glass, the sound continues for a bit, then sound goes out, after one or two minutes the prompt box appears.

I call it a hang, because I could restart FSX right after that, it did not crash the system. But this always happened like this to me.

I said it happens on missions, but they were indeed free flight missions, cause these are the ones I mostly use, specially when configuring settings, but it happens on scripted missions too (abl), I tried them too. It's all I can tell by now.

[peterhayes]

Pete

Just a thought could this be related to my post of a few months ago when I reported: FSUIPC4 "freezes" in FSX Acceleration.

You did an awful lot of investiagtions on my behalf but we never did solve the issue. I no longer run FSUIPC (and miss it deperately) due to this issue.

Maybe there is alink?

Regards

PeterH

[snomhf]

Pete

Just a thought could this be related to my post of a few months ago when I reported: FSUIPC4 "freezes" in FSX Acceleration.

...

Good point, except I would have to change what you're saying here to "freezes in SP2 or Acceleration" because I ran in SP2 (rather than Accel) all last week and the freezing behavior was exactly the same. I wish I had thought to try it before I loaded any patches. It would have been nice to know if it would freeze with SP1 or no patch at all. Oh well, sorry, I'm not going there. I've payed my dues. :) I have gone back to Accel now but since I'm not running my axes in direct mode, I'm seeing no freezes at all.

BTW, I'm supposed to be getting different memory tomorrow so hopefully I can close the door on that possibility completely. I'll let you know what the different memory does.

[Pete Dowson]

To me, it is allways the same situation: the image freezes with the mouse pointer turning to hour-glass, the sound continues for a bit, then sound goes out, after one or two minutes the prompt box appears.

I call it a hang, because I could restart FSX right after that, it did not crash the system. But this always happened like this to me.

No, that's a crash. A hang is when nothing happens and you have to forcibly close FS using the Task Manager.

Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce it, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please?

I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue.

Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less.

In the [Axes] section, set

PollInterval=100

This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second).

If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second).

Thanks!

Regards

Pete

[Pete Dowson]

I would be happy to be a guinea pig for any testing you'd like me to do. As I've said, I can reproduce this problem like clock-work within fifteen minutes. I have, to the best of my ability, eliminated hardware issues, faulty installation, etc. from the equation. I still have the FSUIPC.ini that fails on hand so it's a very quick swap to do it.

Okay, yes please. I'm going at this full time as of now and need information.

Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce the crash, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please?

Also, as I've said elsewhere here, I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue.

Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less.

In the [Axes] section, set

PollInterval=100

This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second).

If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second).

Thanks!

Regards

Pete

[Pete Dowson]

Just a thought could this be related to my post of a few months ago when I reported: FSUIPC4 "freezes" in FSX Acceleration.

You did an awful lot of investiagtions on my behalf but we never did solve the issue. I no longer run FSUIPC (and miss it deperately) due to this issue.

Maybe there is alink?

Were you assigning Axes in FSUIPC for "direct to FSUIPC calibration"? If not then I think it was a different issue, probably related to a SimConnect mis-installation. The thing in common with all these here is direct assignment. As soon as folks simply change the assignment, still in FSUIPC, to an equivalent FS control, it stops the problems.

Regards

Pete

[Muas]

Could you possibly enable SimConnect logging (as described in the FSX Help announcement above), reproduce it, then ZIP up both the SimConnect log and the FSUIPC log and send it to me, please?

I'm looking for a way to bypass SimConnect completely when assigning axis "direct to FSUIPC". I've a feeling that my joystick axis scanning rate may be exceeding SimConnect's "pipe" capacity and the automatic throttling which should occur is cutting in too late, after corruption. Once the data is corrupted anything can ensue.

Meanwhile, there is one other thing you can try to see if it has a beneficial effect: reduce the axis polling frequency (i.e. increase the interval) so that the load on Simconnect is less.

In the [Axes] section, set

PollInterval=100

This quadruples the interval from 10 mSecs (100 polls per second) to 100 mSecs (only 10 per second). If this makes it too unresponsive to fly properly try 50 (20 per second) or 40 (25 per second).

If this severely reduces or even eliminates the crashes/hangs, try a lower number again, say 20 (for 50 polls per second).

Thanks!

Regards

Pete

I'll be glad to do that, but not until next saturday.