FSX is a 32bit application. On a 64bit system it will be run in a virtual WOW64 session, which is basically a 32bit emulator. As such, it's VAS allocation is subject to precisely the same rules that apply to FSX running on a 32bit operating system.That is why I suggested increasing the USERVA by 512MB.

Mr. Leaming I'm not trying to debunk what you are saying here but I still don't understand how the USERVA switch would do anything in a 64-bit OS? Either I'm confused or you're confused and I'm just trying to make sure if there is something I don't understand. If FSX is running in a 32-bit emulator, isn't the VAS still being controlled by the 64-bit OS?Take a look here: http://www.prophotowiki.com/w/index.php/IncreaseUserVaScroll down to almost the bottom of the page where it says "Alternatives: 64-bit Versions" and note that it states:

One way to work around the limitations listed above is to use the 64-bit versions of Windows Vista on a capable computer. As kernel-mode components had to be rewritten for the 64-bit versions of the OS, they are designed to work within a much larger memory space. As such, the functionality provided by this switch is automatically available to any 32-bit software that requests it (such as Photoshop CS2). As this does not require any manual intervention, the user does not need to concern themselves with these details so the use of large banks of memory is much simpler.

Todd

You are not confused. If the LARGEADDRESSAWARE flag is set in the .EXE header, a 64-bit OS will make virtual memory above 2GB available automatically.

You are not confused. If the LARGEADDRESSAWARE flag is set in the .EXE header, a 64-bit OS will make virtual memory above 2GB available automatically.

Yes, and it it should also be highlighted that FSX SP2 and/or Acceleration have the LARGEADDRESSAWARE flags already set in the PE header.With respect to using BCDEDIT to change the USERVA value in a 64-bit OS, 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 Windows Server technet section, 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." So the use of /3GB has been superfluous in a 64-bit environment since at least Windows Server 2003.Technet: 4GT Technical ReferenceThe /3GB switch and its BCDEdit counterpart, INCREASEUSERVA, are meaningless in a 64-bit OS. You can put it there without crashing the system, but it has no effect. In a 64-bit environment, whether that's XP64, Vista 64, or Win 7 64, all 32-bit programs with LARGEADDRESSAWARE flags set in the PE header are allowed 4GB of virtual address space by default, without doing anything extra or special...and FSX SP2 came from MicroShaft already large address aware.RegardsBob ScottColonel, USAF (ret)ATP IMEL Gulfstream II-III-IV-VColorado Springs, CO

Mr. Leaming I'm not trying to debunk what you are saying here but I still don't understand how the USERVA switch would do anything in a 64-bit OS? Either I'm confused or you're confused and I'm just trying to make sure if there is something I don't understand. If FSX is running in a 32-bit emulator, isn't the VAS still being controlled by the 64-bit OS?

Thank you for your kind correction. I've learned something new today and will add this to the Wiki articles to make this point crystal clear. :(

Yes, and it it should also be highlighted that FSX SP2 and/or Acceleration have the LARGEADDRESSAWARE flags already set in the PE header.

ibid my previous reply to Todd. Thank you, Bob for providing something new for me to learn. :(

Thank you for your kind correction. I've learned something new today and will add this to the Wiki articles to make this point crystal clear. :(ibid my previous reply to Todd. Thank you, Bob for providing something new for me to learn. :(

And thank you for your kind response. As I said before I wasn't trying to debunk your statements. I just wanted to make sure that I wasn't confused or misinformed.Todd

Thank you for that little write-up Colonel. That is very interesting and I will save your post so I can refer to it again.