Desktop and FSX freezes every 10 seconds

[funkyp]

Hi Pete,

I have some trouble with the latest 4.558, but I'm not sure if this is not already since 4.53.

Precisely every 10 seconds the entire desktop including FSX SP2 freezes for a second or so. It is clearly not related to any other add-on, as these are all deactivated for testing. Aircraft is stock King Air 350 on EDDK.

It might however sneaked in after falling back to the MS-supplied VISTA display driver, which I did a few days ago, after having continuous trouble with "FSX has stopped working"-errors (the error has remained, btw). I'm going to try the latest NV driver package 195.62 now.

The freeze does not occur when I do not load FSUIPC.

I have prepared a bundle of logs, inis, etc. for information. System is VISTA 64 Home Premium, Asus P5Q, E8400, 4GB, NV9600GT/1GB.

best regards,

Peter

[Pete Dowson]

I have some trouble with the latest 4.558, but I'm not sure if this is not already since 4.53.

Precisely every 10 seconds the entire desktop including FSX SP2 freezes for a second or so. It is clearly not related to any other add-on, as these are all deactivated for testing. Aircraft is stock King Air 350 on EDDK.

There's nothing in FSUIPC with any sort of time interval like that. The only regular actions carried out by FSUIPC are reading the weather data from SimConnect -- but that is much more frequent, and updating the AI traffic information, which is continuous but dependent on SimConnect's notifications. Everything else, all of the offset data obtained for other programs, is all simConnect data notification, which is completely asynchronous. I suppose it is possible for a corrupted SimConnect setup to cause it to get such things bunched up, but it seems very unlikely to me.

I have a similar problem going on on one of my systems, one which was working perfectly on the Windows 7 Ultimate 64 RC release, but not now since updating to the full RTM release. I am suspecting video drivers, as the only time I've had this before was definitely down to the drivers, and was fixed by retreating to an older version. However, I'm also running TrackIR5 on that PC, and its drivers seem to have some problems now too.

On my main FSX setup I'm running the same video driver, the same Win7, the same FSUIPC, and it's perfectly smooth. So hardware differences, probably some IRQ or timing differences, probably also come into it.

If you really think it is 4.558, try reinstalling 4.53 to compare -- you'd need to manually delete the 4.558 version from the FSX Modules folder first, because the Installer won't replace a later version. Let me know please.

It might however sneaked in after falling back to the MS-supplied VISTA display driver, which I did a few days ago, after having continuous trouble with "FSX has stopped working"-errors (the error has remained, btw). I'm going to try the latest NV driver package 195.62 now.

Okay. Let me know about that, too, please.

The freeze does not occur when I do not load FSUIPC.

That can mean it is a SimConnect problem, but it is more likely just happening like that because of small timing differences having FSUIPC included causes.

If I find out what is causing it on the one system it is happening on here, I'll get back to you.

[LATER]

I've re-checked the problem on my PC and it isn't a regular 10 secs. It varies a lot from several long jerks over a few seconds to hardly any for maybe up to 20 or 30. And it's the same with 4.53 or 4.558. I really don't think FSUIPC is the primary cause. I'm going to re-test without TrackIR5 running first, then look for a later driver (I've been using 182.50 for a long time without problems).

Regards

Pete

[funkyp]

Hi Pete,

Thanks fro the quick reply. After installing the latest NV driver 195.62 the problem is gone again. Until recently I used 191.62, which seemed to have worked either. Seems that the graphics driver distributed by the MS driver base has been the cause of the problem.

Though, it makes me currious how this gets triggered by some SimConnect Add-on that does not interfere with graphics at all. Some indicator that something is weird is a long sequence of alternating RequesID=14 and RequestID=24's in the SimConncet.Log (c.f. below). This starts at 83.98635 seconds, then comes the break until 85.1349 seconds. Apparently, a number of the 14ers and 24ers have queued up which are flushing now into FSUIPC. There were no transmits before from FSUIPC after 83.2 s or so, when only the SimState was requested, so indeed, it doesn't seem to have anything to do with FSUIPC directly.

I have also some trouble with a Windows 7 test installation, where it turned out that out-of-process add-ons gets way less reliably queued compared to XP and VISTA (indeed VISTA is much better here). It urges me to move some time critical parts of my app into a new DLL.

As it seems fixed I'm not going to try 4.53 for the moment.

best regards,

Peter

[EDIT]: I can confirm that the Windows 7 jerks are a completely different story, and I can confirm your findings about irregularity. In out-of-process add-ons it is very relevant and I found up to 0.5 seconds delay in activation of the add-on even with 195.62. In in-proc-DLLs it is much better, but still not as good as in Vista and XP.

< 83.95244 [0] EventFrame: 0  29.908175
< 83.95266 [0] ObjectData: RequestID=9  DefineID=9  dwSize=56
< 83.95280 [0] ObjectData: RequestID=10  DefineID=10  dwSize=400
< 83.98502 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 83.98523 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 83.98549 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 83.98566 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 83.98598 [0] EventFrame: 0  29.859402
< 83.98622 [0] ObjectData: RequestID=9  DefineID=9  dwSize=56
< 83.98635 [0] ObjectData: RequestID=10  DefineID=10  dwSize=388
< 85.13849 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 85.13894 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 85.13969 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 85.14020 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 85.14193 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 85.14225 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 85.14281 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 85.14542 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 85.14655 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 85.14771 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 85.14808 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208
< 85.14835 [0] ObjectData: RequestID=24  DefineID=24  dwSize=68
< 85.14873 [0] ObjectData: RequestID=14  DefineID=14  dwSize=208

[Pete Dowson]

Thanks fro the quick reply. After installing the latest NV driver 195.62 the problem is gone again. Until recently I used 191.62, which seemed to have worked either. Seems that the graphics driver distributed by the MS driver base has been the cause of the problem.

I've eliminated TrackIR5 and assorted unnecessary services running in the background. I'm downloading the latest nVidia drivers now to try -- 195.81 from guru3d.com. I think they are pretty much the same as the official 195.62.

There are certainly good and bad drivers. I found lots of bad ones before I took notice of the general consensus that 182.50 were about the best for FSX. That did indeed seem to be the case for me -- until updating from the RC release of Win7 to the full user release. Strange.

Though, it makes me currious how this gets triggered by some SimConnect Add-on that does not interfere with graphics at all.

My guess is only that there are critical timing differences in drivers which just hit some beat frequency in other activities in FSX -- FSUIPC sometimes, other things like FS's own flight computations another. These stutters and jerks are a frequent problem with or without FSUIPC, and certainly driver changes do seem to always affect them.

Some indicator that something is weird is a long sequence of alternating RequesID=14 and RequestID=24's in the SimConncet.Log (c.f. below). This starts at 83.98635 seconds, then comes the break until 85.1349 seconds. Apparently, a number of the 14ers and 24ers have queued up which are flushing now into FSUIPC. There were no transmits before from FSUIPC after 83.2 s or so, when only the SimState was requested, so indeed, it doesn't seem to have anything to do with FSUIPC directly.

Without looking at my code I can't say exactly what those data blocks are for, but they are related to changes in the simulator situation -- engine, position, whatever. They aren't AI Traffic ones, nor weather, that's all I can say without checking. They are sent to FSUIPC asynchronously, just when the values change, being only requested once at FSX/FSUIPC4 initialisation.

Anyway, glad you are sorted. I'm off to try the newer video drivers now ...

[LATER]

Well, the later drivers fixed the TrackIR problems. I was a bit concerned, though, when FSX, TrackIR and the whole PC locked up solid after only about 30 seconds of FSX flying. I powered off and on and tried again, and it didn't hang again, so I'm keeping my fingers crossed! The pauses/freezes are gone, but I still have "microstutters". Time to play with some of the settings again I thinkI don't know. Seems that FS is all about pottering about doing this, that and the other with a tiny bit of flying in between, if you're lucky!

Happy Christmas,

Pete

Regards

Pete

[Andydigital]

Seems that FS is all about pottering about doing this, that and the other with a tiny bit of flying in between, if you're lucky!

So so true.

What's even more irritating is when you have one of those flights where everything goes perfectly one day and you come away from the PC thinking it cant get any better than this, then the next day or even later on the same day sometimes FSX runs like a dog and you feel like jacking it all in and throwing the bloody thing out the window :lol:

[funkyp]

It seems to me more like a model railway. It's not about having the trains running all the time but creating the landscape and making it all neat and as real as it gets. At the end of the day you roll a few trains for half an hour or so, pleased with the realism of your own good work, and then go to bed happily.

The other day, you'll start with the next "challenge".

Merry Christmas,

Peter