N4Gix, just wanted to tell you that windows uses the WOW64 kernel to run 32-bit applications and WOW32 to run 16 bit applications. Therefore since FSX is 32bit, it uses WOW64 (for those that don't know it Windows on Windows 64). Hope you don't take this the wrong way :(, just wanted to clear it up incase someone googled it, or so it doesn't become misused :(

Gman.. what Bill stated about the address space for Vista x64 and a 32bit application that is not marked LARGE ADDRESS WARE is correct and I think what he posted was simply a typo as he does understand the WOW system. However in this case we are dealing with a unstable clock from an inexperienced clocker, and, a series of very ridiculous FSX.cfg settingsOn top of that, this system in its BIOS has a feature for the northbridge known as: MEMORY REMAPWhat that does and MUST BE ENABLED for a 64bit OS is allows for the segment of system memory that was previously overwritten by the PCI configuration space to be remapped above the 4 GB address line.. In his case I believe this is DISABLED and will confirm it tomorrow however based on the issue and the rest of the BIOS settings I would put a 10 grand bet on it being disabled. The combination of all of the above is what, at this point, I firmly believed forced a very RARE OOM in Vista 64 with FSX SP2 installed. He never should have manipulated userva in this system and it will need to be restored to default which we are working on in hardware now.If after we get him set up correctly he still OOM's it will be the result of a improperly designed addon, not address space issues with Vista 64, and at that point we will address the addon itself however seeing all the issues involved I do not think that will end up being the case.

Gman.. what Bill stated about the address space for Vista x64 and a 32bit application that is not marked LARGE ADDRESS WARE is correct. However in this case we are dealing with a unstable clock from an inexperienced clocker, and, a series of very ridiculous FSX.cfg settingOn top of that, this system in its BIOS has a feature for the northbridge known as: MEMORY REMAPWhat that does and MUST BE ENABLED for a 64bit OS is map PCIe video memory over the physical memory. In his case I believe this is DISABLED and will confirm it tomorrow however based on the issue and the rest of the BIOS settings I would put a 10 grand bet on it being disabled. The combination of all of the above is what, at this point, I firmly believed forced a very RARE OOM in Vista 64 with FSX SP2 installed. He never should have manipulated userva in this system and it will need to be restored to default which we are working on in hardware now.If after we get him set up correctly he still OOM's it will be the result of a improperly designed addon, not address space issues with Vista 64, and at that point we will address the addon itself however seeing all the issues involved I do not think that will end up being the case.

????? :( I was talking about Wow64 and Wow32 and how the kernels are used. I am confused. Wow64 runs 32 bit apps and Wow32, which is no longer included on the latest version of Windows (Vista), runs 16-bit apps. In his wikiw and in the thread he said Wow32 is what runs 32 bit apps on Windows 64 bit, but its no big problem :(. I'm not talking about the userVA, just Windows on Windows :(.

I was editing my post when you responded.. I simply meant, Bill is correct about the address space use and I think it was just a typo..

I was editing my post when you responded.. I simply meant, Bill is correct about the address space use and I think it was just a typo..

Sorry :(. I bet it is a small typo, because according to my calculations, they are very easy to get confused. :( :(

Sorry :(. I bet it is a small typo, because according to my calculations, they are very easy to get confused. :( B)

No worriesBills knowledge of MSFS in XML, coding and the SDK is quite impressive. He far exceeds me in those areas and has always extended a highly experienced helping hand when I have a question. We all have our talents and gifts. This forum and the hobby would not be the same without Bill and his knowledge around MSFS should never be discounted.Its all about sharing and discovery.. we all learn something from each other :(

Sorry :(. I bet it is a small typo, because according to my calculations, they are very easy to get confused. B) B)

Thank you for pointing it out though! It was indeed a typo, and I have now corrected both the Wiki article and my previous post... :( Between typing Vista x32 and Vista x64 and WinXP 32 it's easy to get fumble-fingered... :(

Thank you for pointing it out though! It was indeed a typo, and I have now corrected both the Wiki article and my previous post... :( Between typing Vista x32 and Vista x64 and WinXP 32 it's easy to get fumble-fingered... :(

common Bill.. you and I both suffer from time to time from the same infliction. Its called: "senior moments" :( Its inevitable those issues will come up for us B) I get them a lot more than I like to admit now-a-days The way I look at it, as long as I can still pilot and can tell port from starboard, I

Hi, I just got the above message after the game crashed. You can see my machine is pretty powerful. I have not had this message before and was using photoscenery, with no autogen, the game was running very well and smoothly beforehand. Is this common? Do I need more memory? Does it mean graphics memory or RAM ? Thx, Mark

I'm sorry to chip in at this late stage with an obvious suggestion: but are you absolutely sure you've set the operating system to control the swap file? On a 64-bit OS, this error message is USUALLY a sign that the OS does not have a big enough swap file.As for the rest of this discussion: at the risk of stirring up a hornet's net, my own understanding - based on my own experience as well as what I've read - is that the /3GB etc settings make no difference in Vista 64 and XP 64. See here for what I think is a pretty authoritative statement on this: http://msdn.microsoft.com/en-us/library/bb147385.aspx The same is, I think, evident from a careful reading of this table - which you can get to via one of Fr Bill's links: http://msdn.microsoft.com/en-us/library/aa366778.aspxThe significant point is that in Vista/XP 64 the maximum addressable space for a 32-bit application is 4GB, provided the "large_address_aware" flag is set (which it is, by default, in FSX SP1 onwards). In Vista/XP 32, the maximum addressable space for a 32-bit application is only 3GB, but you have to apply all of Bill's tweaks to get that much. But those tweaks do not increase the addressable space for Vista 64.Tim

His page file is finehe is not exceeding the commit charge with that system or any addons based on his stated page file sizeon top of that, there are two types of process to the virtual memory which do not affect the commit charge limit which is private and pagefile

The system I have has also DDR18000 memory, but I was never able to run it at 1800.I had several email contacts about that with OCZ and at the end it had probably to do with the oc from the board.Even after having tried all there Bios suggetions for several days.Also the moment recently I hooked up a second monitor for desktop expansion and used a Matrox DualHead2Go I even had to clock back a bit more.Imho it all comes down to the maximum of stress the weakest part of the hardware can handle.I am thinking about putting 2 Gb of DDR1800 memory extyra in my system as sometimes ( when using the PMDG MD-11 in detailed scenery with many small waters , with REX clouds and ASA ) above the Netherlands the memory left goes down to even 700mb and than I can see that the system starts to struggle.And I am sure that than I have to clock back again a little.But that's all part of the game.

Nick is a good friend of mine, but in this instance he is incorrect:I've already posted the reaon why (which is stated by Microsoft). When running any 32bit application under Vista x64, it is loaded under the WOW64 kernal. Because of this, it will behave precisely as though it were running under Vista x32. The only real difference being that under Vista x64/WOW64, the maximum VAS table increases from 3MB to 4MB if one (re)sets the boundary between the Application-slice and the OS-slice.http://msdn.microsoft.com/en-us/library/aa366778.aspx

Hi Bill; I'm certain that you are carrying a misconception on the use of INCREASEUSERVA with 64-bit Windows OS's. If you look at Microsoft's BCDEDIT user's reference, page 30, in the detail for the memory options in BCDEDIT, in the section for INCREASEUSERVA, it clearly says that "this data type is not used for 64-bit versions of Windows." Microsoft BCDEdit ReferenceFurther, in the older Windows Server technet section that you referenced us to, with regards to 4GT (4-gigabyte tuning, aka the /3GB switch) it says: "Note: 4GT is not required on the 64-bit versions of the Windows Server 2003 family." I read that to say that the use of /3GB has been superfluous in a 64-bit environment since at least Windows Server 2003.Technet: 4GT Technical ReferenceMy understanding is that the /3GB switch and its BCDEdit cousin, INCREASEUSERVA, are meaningless in a 64-bit OS. You can put it there without crashing the system, but it has no effect. All 32-bit programs with LARGEADDRESSAWARE set in the PE header are allowed 4GB of VAS by default.RegardsBob ScottColonel, USAF (ret)ATP IMEL Gulfstream II-III-IV-VColorado Springs, CO

Hi Bill; I'm certain that you are carrying a misconception on the use of INCREASEUSERVA with 64-bit Windows OS's. If you look at Microsoft's BCDEDIT user's reference, page 30, in the detail for the memory options in BCDEDIT, in the section for INCREASEUSERVA, it clearly says that "this data type is not used for 64-bit versions of Windows." Microsoft BCDEdit ReferenceFurther, in the older Windows Server technet section that you referenced us to, with regards to 4GT (4-gigabyte tuning, aka the /3GB switch) it says: "Note: 4GT is not required on the 64-bit versions of the Windows Server 2003 family." I read that to say that the use of /3GB has been superfluous in a 64-bit environment since at least Windows Server 2003.Technet: 4GT Technical ReferenceMy understanding is that the /3GB switch and its BCDEdit cousin, INCREASEUSERVA, are meaningless in a 64-bit OS. You can put it there without crashing the system, but it has no effect. All 32-bit programs with LARGEADDRESSAWARE set in the PE header are allowed 4GB of VAS by default.RegardsBob ScottColonel, USAF (ret)ATP IMEL Gulfstream II-III-IV-VColorado Springs, CO

I think, if I may repeat myself, that this is exactly right.Sorry if I've missed something but I can't spot where the OP says that he has eliminated the swap file setting as a cause of difficulty. I see that Nick_N thinks the swap file has nothing to do with it and he has a pretty strong track record about things like this. But I do hope that the OP will at least TRY getting Windows to handle all his swap file needs automatically and see whether it makes any difference. In my case, this simple step immediately cleared up the ONLY OOM error I have had with FSX (or anything else) under Vista 64. It also respects the "official" advice from MS, here: http://support.microsoft.com/kb/892610/en-usI have to say that an OOM error sounds like an odd symptom if the problem is with the over-clocking. Whenever I've had problems with over-clocking, the symptoms have been much ruder: usually just a crash, with no nice error report, often with a BSOD. It's got to be worth trying the MS recommeded solution before spending a lot more effort trying to isolate a hardware/configuration fault.Tim

No, it does not sound oddLets all back up a minuteI never defined the OOM error as: "OVERCLOCKING CAUSED OOM"1. The OP

Hi Bill; I'm certain that you are carrying a misconception on the use of INCREASEUSERVA with 64-bit Windows OS's. If you look at Microsoft's BCDEDIT user's reference, page 30, in the detail for the memory options in BCDEDIT, in the section for INCREASEUSERVA, it clearly says that "this data type is not used for 64-bit versions of Windows."

Thanks, Bob. I've removed my earlier posts which were obviously incorrect, rather than infect others with my own inadequate understanding... :(

Thanks, Bob. I've removed my earlier posts which were obviously incorrect, rather than infect others with my own inadequate understanding... :(

Oh well, we all miss a detail every now and then. But thanks for "infecting" us with all the other stuff you've posted on gauge programming over the last few years.CheersBob ScottColonel, USAF (ret)ATP IMEL Gulfstream II-III-IV-VColorado Springs, CO