O.O.M. when accessing too many pop-up panels...

[Sesquashtoo 2,846]

I've noticed that if you access pop panels too many times during a flight, you can generate an O.O.M. FSX freeze-up or CTD.Does W7 not release memory locations when you reduce the pop up panel? I believe that it does not..and each pop-up 'call' adds to the stack until you reach O.O.M. critical.You either have animation freeze upon you, or C.T.D.If I don't call up pop-ups beyond a couple of times per flight, I don't run the risk of animation freeze up.Had anybody else noticed that memory doesn't get released back to the system after a pop-up 'call' ?I was flying the Citation Mustang, and accessing the pop-ups quite regularly en route. I had an animation freeze in this session. Is there a correlation?Mitch

[altstiff 71]

Are you running a 64bit O/S?

[audiohavoc 24]

You could be on to something. I had an O.O.M. crash in FSX despite running W7 64-bit and 6GB of memory (I know FSX can't use more than 4GB). This happened towards the end of a Concorde-X flight on approach to KJFK. The Concorde-X is an aircraft that requires a large amount of pop-up 2D panels to operate, and there could be a relation between my crash and being at the end of a flight where I had been using 2D pop-ups extensively.

[Illegitimi non carborundum 4]

MitchIt will probably be related to the airplane and the code that was written for it. I would suspect an issue with .NET framework using unmanaged memory (as opposed to managed memory) and the Microsoft Garbage Collector not being able to clear this 'unmanaged memory' and eventually even in a 64-bit OS you will exceed the 4GB Virtual address space and see an OOM.If you ran PERFMON with the following performance counters for the application ie FSX with the plane loaded: Note: Perfmon is not the easiest of MS apps to run or interpret)Process/Private Bytes, .NET CLR Memory/# Bytes in All Heaps, and .NET CLR LocksAndThreads/# of current logical Threads. In the case of a memory leak you would see:If an application's logical thread count is increasing unexpectedly, thread stacks are leaking. If Private Bytes is increasing, but # Bytes in All Heaps remains stable, unmanaged memory is leaking. If both counters are increasing, memory in the managed heaps is building up.If it is not due these then you would then have to look at other counters to see what is going on.You could try after each (pop-up) and this will be tedious of reducing FSX to the desk top and then restoring it which would hopefully clear the issue - but with FSX who knows? Ref:http://msdn.microsoft.com/en-us/magazine/cc163491.aspx and http://msdn.microsoft.com/en-us/library/ee787088%28v=VS.100%29.aspxIts a complex subject and may have more causes than I have delved into here! :( RegardsPeterH

[Sesquashtoo 2,846]

Are you running a 64bit O/S?

Yes, W7 64 Ultimate

[Sesquashtoo 2,846]

You could be on to something. I had an O.O.M. crash in FSX despite running W7 64-bit and 6GB of memory (I know FSX can't use more than 4GB). This happened towards the end of a Concorde-X flight on approach to KJFK. The Concorde-X is an aircraft that requires a large amount of pop-up 2D panels to operate, and there could be a relation between my crash and being at the end of a flight where I had been using 2D pop-ups extensively.

Yeppers...that was my experience, also. I have plenty of RAM and of course as you, running in 64 bit mode. I had been en route in the F1 Mustang, and doing navigation and other things needing my bringing up the 2D-pop ups. After about five 2D pop-up sessions,.....an animation freeze (which I am starting to believe is caused by an exhausted memory stack) and a O.O.M. CTD ensued.Mitch

[Sesquashtoo 2,846]

MitchIt will probably be related to the airplane and the code that was written for it. I would suspect an issue with .NET framework using unmanaged memory (as opposed to managed memory) and the Microsoft Garbage Collector not being able to clear this 'unmanaged memory' and eventually even in a 64-bit OS you will exceed the 4GB Virtual address space and see an OOM.If you ran PERFMON with the following performance counters for the application ie FSX with the plane loaded: Note: Perfmon is not the easiest of MS apps to run or interpret)Process/Private Bytes, .NET CLR Memory/# Bytes in All Heaps, and .NET CLR LocksAndThreads/# of current logical Threads. In the case of a memory leak you would see:If an application's logical thread count is increasing unexpectedly, thread stacks are leaking. If Private Bytes is increasing, but # Bytes in All Heaps remains stable, unmanaged memory is leaking. If both counters are increasing, memory in the managed heaps is building up.If it is not due these then you would then have to look at other counters to see what is going on.You could try after each (pop-up) and this will be tedious of reducing FSX to the desk top and then restoring it which would hopefully clear the issue - but with FSX who knows? Ref:http://msdn.microsoft.com/en-us/magazine/cc163491.aspx and http://msdn.microsof...=VS.100%29.aspxIts a complex subject and may have more causes than I have delved into here! RegardsPeterH

--------------------------------------------------------------------Thanks for the in-depth 'possible', Peter. If you are also running W7 64 and have the F1 Mustang, take it up for a spin.....for a flight of around 500 miles....access the panels around10 times bringing up the 2D pop-ups, and see what happens to your flight. It sounds like you have a much better technical 'handle' on what might be happening than I. If you don't get an O.O.M. at around ten, then I invite you to, at intervals of your choice, that you keep bringing up and closing the 2D pop ups until you land, and then post what occurred.Mitch

[Illegitimi non carborundum 4]

MitchI will try it on a Vista 64 and on a win 7 64 rig and see what happens! :( Did you get the same result if you decreased the sliders to the left?This could just be a theory and it may be something else entirely.One thing I have never experienced an OOM error with a plain vanilla install of FSX! Hmmm!RegardsPeterH

[Hirgab 9]

I had the EXACT SAME problem.There is a VERY VERY simple fix for this. VERY simple.Simply, download uiautomationcore.dll from Vista and overwrite the one on your W7 64bit.I've attached the file. Do exactly as I state above. Backup your old file first.PROBLEM SOLVED! ....let me know.

[audiohavoc 24]

I had the EXACT SAME problem.There is a VERY VERY simple fix for this. VERY simple.Simply, download uiautomationcore.dll from Vista and overwrite the one on your W7 64bit.I've attached the file. Do exactly as I state above. Backup your old file first.PROBLEM SOLVED! ....let me know.

Afraid not, I already have the uiautomationcore.dll, which fixed crashes related to accessing menus in FSX, not pop-up 2D panels. Thanks for trying to help though.

[Guest wims]

You could be on to something. I had an O.O.M. crash in FSX despite running W7 64-bit and 6GB of memory (I know FSX can't use more than 4GB). This happened towards the end of a Concorde-X flight on approach to KJFK. The Concorde-X is an aircraft that requires a large amount of pop-up 2D panels to operate, and there could be a relation between my crash and being at the end of a flight where I had been using 2D pop-ups extensively.

That has happened to me on the ground at KJFK just vacating the runway with ConcX as well. I was surprised when it ran out of memory, but I guess it makes sense. I havent run out of memory on CTP with the MD-11 tho, where I had to use popup panels all the time, but perhaps it was still less than what's required with concx. I also remember spending a lot of time on the ground at EGLL before departing with ConcX, getting familiar with the engineers 2d panelsAnd yes, the UIAutomationcore.dll error has nothing to do with OOM errors.

[jjjallen 37]

That has happened to me on the ground at KJFK just vacating the runway with ConcX as well. I was surprised when it ran out of memory, but I guess it makes sense. I havent run out of memory on CTP with the MD-11 tho, where I had to use popup panels all the time, but perhaps it was still less than what's required with concx. I also remember spending a lot of time on the ground at EGLL before departing with ConcX, getting familiar with the engineers 2d panelsAnd yes, the UIAutomationcore.dll error has nothing to do with OOM errors.

I just got this OOM error today (can't remember the last time) and sure enough I was using many 2D popups much more than normal. I will keep tabs on my 2D popup usage from now on.thanksjja

[altstiff 71]

Are you guys using SP2 for FSX? As the FSX.EXE is flagged with the Large Address Aware fix by defualt (in SP1 and original I do not think it is).I was under the impression that 64bit with the LAA flag could use up to 16GB of VA space. That seems like plenty to go through on the ramp before a flight no?

[audiohavoc 24]

I am using FSX w/ Acceleration and Windows 7 64. Hardware is in my signature.

[virtuali 4,419]

I was under the impression that 64bit with the LAA flag could use up to 16GB of VA space. That seems like plenty to go through on the ramp before a flight no?

FSX it's a 32 bit app so, by default those apps can only address 2GB, even on a 64 bit OS. Those compiled with LARGEADDRESSAWARE flag can go up to 4GB. A 32 bit app under a 32 bit OS could only go up to 3G even with the LARGEADDRESSAWARE so, the difference between 32 and 64 OS, for 32 bit apps, it's that extra 1GB. Only true 64 bit apps can address up to 8TB.See this table at Microsoft site:http://support.microsoft.com/kb/889654/en-us