"Out Of Memory" Crash with FSUIPC4.306/WideFS7

[Björn]

Hello Peter,

I'm experiencing a strange problem with FSUIPC 4.306. Every time I get to a certain distance from a certain fix on my flight plan, my FSX crashes displaying the message that my computer has run out of Ram.

It's not the first time I've flown on that route, it's one of my favourite airliner routes and I could fly it blindly by now. I've never had problems before flying on it, but after I purchased and installed Radar Contact 4.3 and FSUIPC4 + WideFS7, the troubles started. Not only on this single route, but also before that, on my inaugural flight with RC4 (again, the OOM error, but I blamed it on too much AI traffic when I passed by KORD on approach into KMDW).

I think my system is well up to the task (E6600 overclocked, 2Gb PC800 Ram, 8800GTS 640Mb overclocked, XP SP3) and my FSX (SP1) used to show occasional OOM errors, but only without having the "/3GB /Userva=2560" and "FSX can allocate more than 2Gb of Ram" tweaks applied. With those fixes, the sim runs a-ok and error-free.

Anyway, upon deciding to purchase RC4.3, I also decided to turn my FSX PC into a WideFS/Simconnect server and let my laptop (also up to the task) run ASX (instead of my main PC) and RC4.3 to free up some more system ressources for FSX.

I needed to fiddle quite a bit to get everything running, but everything worked in the end. ASX connected to FSX via SimConnect, like it should and RC4.3 ran via WideFS7 like it should - well, except for the FSX crash.

When I first encountered this problem, I suspected it being a driver (running a beta NVidia driver, this was a fairly possible cause) or RC4/ASX error, so I tried again without running those two extra tools and a new graphics card driver...the result was the same - OOM. I then reinstalled FSUIPC4.3, but without registering both FSUIPC and WideFS, and started another try running only ASX via SimConnect - the error didn't occur.

Today, I wanted to reproduce the error, but with extensive FSUIPC logging (all options) enabled. I encountered the same error again, but being the idiot I am, I didn't back up the log and started FSX again afterwards (to check something else) - the result: The log vanished. :oops:

Yet, since the error is perfectly reproducable, I'm gonna report back in tomorrow with FSUIPC, WideServer and WirdClient logs.

Do you need anything else, like a SimConnect log?

I hope this posting is already giving you an idea about the nature of the error.

Regards,

Björn

P.S: At the moment of the FSX crash, Ram usage is at 94% - a normal level.

P.P.S: The route is from EDDV to LKPR and the crash occurs about 60 miles from the first fix (ERF).

P.P.P.S: I've also tried the 4.3 version of FSUIPC - same results.

[Pete Dowson]

I'm experiencing a strange problem with FSUIPC 4.306. Every time I get to a certain distance from a certain fix on my flight plan, my FSX crashes displaying the message that my computer has run out of Ram.

Neither FSUIPC nor WideFS use much RAM at all, and certainly don't use anything progressively.

Yet, since the error is perfectly reproducable, I'm gonna report back in tomorrow with FSUIPC, WideServer and WirdClient logs.

Do you need anything else, like a SimConnect log?

Sorry, but none of that will be of any use, as there will be nothing indicating RAM problems as none of my stuff is a big or Continuous RAM user. You need to track down what might be causing a leak. It is almost always associated with graphics, things like scenery, textures, terrain, landclass, but with Network use it could also occur when the TCP/IP subsystem runs out of buffers space.

If your normal RAM usage is 94% then any extra complication such as adding or enabling the things you mention could cause the problem. Do you have adequate paging file space? Try running without ActiveSky, as it may be related to the large numbers of TCP/IP buffers being used. Is the geographic area one with quite a few WX stations around?

Regards

Pete

[Björn]

Sorry, but none of that will be of any use, as there will be nothing indicating RAM problems as none of my stuff is a big or Continuous RAM user. You need to track down what might be causing a leak. It is almost always associated with graphics, things like scenery, textures, terrain, landclass, but with Network use it could also occur when the TCP/IP subsystem runs out of buffers space.

The thing is, that I haven't done anything regarding adding scenery and changing graphics settings between the pre-WideFS state (which, as I said worked fine) and the current state.

I'd like to look into the "TCP/IP buffers" matter. Could you tell me more about it?

If your normal RAM usage is 94% then any extra complication such as adding or enabling the things you mention could cause the problem. Do you have adequate paging file space?

My page file is set at a fixed 3072Mbytes. I think it's enough.

Try running without ActiveSky, as it may be related to the large numbers of TCP/IP buffers being used. Is the geographic area one with quite a few WX stations around?

Yes, there are a lot of stations around.

I'm going to fly the route without ASX running the next time and report back.

Thanks for the help so far, Pete.

Björn

- Edit: The PC and laptop are connected via wireless LAN. Could this be a factor?

[Pete Dowson]

The thing is, that I haven't done anything regarding adding scenery and changing graphics settings between the pre-WideFS state (which, as I said worked fine) and the current state.

No, but you've added more activity. If your system was near the edge already that might just have been enough.

now I'm not saying there SHOULD be OOM failures. That really indicates a severely fragmented memory rather than actual shortage of memory, so it can occur at 94% if FS needs a contiguous block of a few megabytes and can't get it. The trouble really is that nothing is doing regular de-fragging of the memory allocations. You can install programs which take care of this, but then you tend to be adding stutters to the simulation as those programs do their stuff.

Most times I've read about someone getting OOM problems with FS the answer was to reduce some display settings or reduce other activities somehow. In FS2004 there was also the memory leakage problems most often apparently caused by combinations of scenery (landclass) files incorrectly placed.

I'd like to look into the "TCP/IP buffers" matter. Could you tell me more about it?

Well, I don't know any more -- only that the TCP/IP traffic uses memory same as everything else, so adding more regular traffic increases the load on the memory and so also the fragmentation.

My page file is set at a fixed 3072Mbytes. I think it's enough.

Yes, so it is going to be lack of continuous real memory when FS requests it.

Edit: The PC and laptop are connected via wireless LAN. Could this be a factor?

Possibly. I really don't know if that makes a difference to memory usage.

t might be worthwhile searching in the FSX forum here fr reports and solutions to memory issues with FSX. I seem to remember seeing several there.

The main thing I just noticed, though, is that you said you are using FSX with only SP1. Why haven't you added SP2? It does make SimConnect much much more efficient and in fact avoids TCP/IP altogether for all local SimConnect interactions (such as that with FSUIPC, TrackIR and local add-ons). SP2 is really an essential fix for FSX, so I think that should be your first step.

Regards

Pete

[Björn]

No, but you've added more activity. If your system was near the edge already that might just have been enough.

I thought I was taking away activity by running the tools via network instead of in the background.

Well, I don't know any more -- only that the TCP/IP traffic uses memory same as everything else, so adding more regular traffic increases the load on the memory and so also the fragmentation.

So basically, increasing the buffer size won't solve my problem.

The main thing I just noticed, though, is that you said you are using FSX with only SP1. Why haven't you added SP2? It does make SimConnect much much more efficient and in fact avoids TCP/IP altogether for all local SimConnect interactions (such as that with FSUIPC, TrackIR and local add-ons). SP2 is really an essential fix for FSX, so I think that should be your first step.

Well, I know about SP2, but it brought me nothing but trouble, even after a veryveryveryvery "by the book" reinstall of everything. I began encountering microstutters when there were none before and, most important of all, I had to disable ground shadowing to make my AI traffic show up at add-on airports - not much of an acceptable solution for me, since AI traffic is one of the most important elements for me in FSX.

I still have access to the SP2 SimConnect though (the Installer from the SP2 SDK) as well as an entire zipped up FSX SP2 folder (for backup purposes and/or if I need to cannibalize some SP2 files).

I think I'm going to give SP2 SimConnect a try, but I have a bad feeling about ASX.

Björn

[Pete Dowson]

I thought I was taking away activity by running the tools via network instead of in the background.

Processor activity, maybe not memory demands.

Well, I know about SP2, but it brought me nothing but trouble, even after a veryveryveryvery "by the book" reinstall of everything. I began encountering microstutters when there were none before and, most important of all, I had to disable ground shadowing to make my AI traffic show up at add-on airports - not much of an acceptable solution for me, since AI traffic is one of the most important elements for me in FSX.

Well, I don't know what is causing that (though FSX reinstalls seem to cause more problems than anything, unless you also reinstall Windows), but SP2 was and is a significant improvement to many many parts of FSX and most certainly streamlines SimConnect-using applications, especially FSUIPC, TrackIR and other local-to-FSX applications. I have no idea why you had problems with SP2, but I really do think you need to sort them.

I still have access to the SP2 SimConnect though (the Installer from the SP2 SDK) as well as an entire zipped up FSX SP2 folder (for backup purposes and/or if I need to cannibalize some SP2 files).

It isn't any use having the SP2 SimConnect installed in Windows when the core SimConnect support, which is in FSX, is still SP1 or before. The problem of TCP/IP usage in SP1 and before concerns the communication between the SimConnect.DLL (the one in the Windows Side-by-Side folders) and FSX proper. If FSX proper is still at SP1 level it forces SimConnect connections to be at the same level. You can only use SP2's SimConnect if you update FSX to SP2. That's where the SimConnect code really is. The DLL's installed by the SDK are simply interface routines for applications.

Regards

Pete

[Björn]

Sorry for the late reply, Pete.

Well, I don't know what is causing that (though FSX reinstalls seem to cause more problems than anything, unless you also reinstall Windows), but SP2 was and is a significant improvement to many many parts of FSX and most certainly streamlines SimConnect-using applications, especially FSUIPC, TrackIR and other local-to-FSX applications. I have no idea why you had problems with SP2, but I really do think you need to sort them.

With a heavy heart, I've given SP2 another shot. Installed it, defragged the disk and configured it (fresh fsx.cfg). The performance issues seem to be gone and I'm just taking a test flight from EDDV to LKPR with RC4 and ASX running in the background, and so far, it's looking really good, apart from some very short, normal ASX-induced hiccups. It felt really great passing my "dead end" at ERF without a hitch.

Ram usage is fairly normal as well.

I'm still in the air (it's kind of cool having two PCs... :)) and I'll certainly report back when I'm back on the ground. Maybe I'll even make the return flight right after for testing.

- Edit: Parked and secured now. No freeze-up at all, looks like SP2 did the trick.

Thank you for your help, Pete!

[Pete Dowson]

... looks like SP2 did the trick.

Good. Let's hope it stays good for you.

Regards

Pete

[Björn]

The return flight went a-ok as well. Looks like the problem is eliminated.

Thanks for the help, Pete!