FSX crash caused by simprop.dll


One of our regular visitors ran in a severe problem after he had repaired FSX using the DvD’s. After starting FSX the sim crashed and with the event manager it indicates that simprop.dll (in the root of FSX) was the fault module. Before the repair action FSX was in SP2 mode (without Acceleration).
Resolution: After a repair action with the DVD’s you must run the SP1 servicepack as well as the SP2 servicepack. First run SP1 and then start FSX in default flight. Close FSX, then run SP2. When starting SP2 you will see no option to install….only to uninstall, so uninstall.  After uninstall, re-run SP2 again, start FSX and your problem with simprop.dll is solved.

 

4GB Patch for FSX.EXE


Lets’ start with current available information from MSDN:
On 32-bit editions of Windows, applications have 4 gigabyte (GB) of virtual address space available. The virtual address space is divided so that 2 GB is available to the application and the other 2 GB is available only to the system.
The 4-gigabyte tuning (4GT) feature, formerly called 4GT RAM Tuning, increases the virtual address space that is available to the application up to 3 GB, and reduces the amount available to the system to between 1 and 2 GB.
For applications that are memory-intensive, such as our FSX app, the use of a larger virtual address space can provide considerable performance and scalability benefits.

However, the file cache, paged pool, and nonpaged pool are smaller, which can adversely affect applications with heavy networking or I/O. Therefore, you might want to test your application under load, and examine the performance counters to determine whether your application benefits from the larger address space.
To enable 4GT, use the BCDEdit /set command to set the increaseuserva boot entry option to a value between 2048 (2 GB) and 3072 (3 GB).
The /3GB switch is supported on 32-bit editions like Windows XP Professional, VISTA, W7X32.

The /3GB switch makes a full 3 GB of virtual address space available to applications and reduces the amount available to the system to 1 GB. On Windows Server 2003, the amount of address space available to applications can be adjusted by setting the /USERVA switch in Boot.ini to a value between 2048 and 3072, which increases the amount of address space available to the system. This can help maintain overall system performance when the application requires more than 2 GB but less than 3 GB of address space.

To enable an application to use the larger address space, set the IMAGE_FILE_LARGE_ADDRESS_AWARE flag in the image header. The linker included with Microsoft Visual C++ supports the /LARGEADDRESSAWARE switch to set this flag. Setting this flag and then running the application on a system that does not have 4GT support should not affect the application.

On 64-bit editions of Windows, 32-bit applications marked with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag have 4 GB of address space available.

fsx_exe_4GB.PNGThis very little tool patches our x86 executable fsx.exe in order to let it have 4GB (instead of only 2GB) of virtual memory on x64 platforms. To gain these 2GB, you just have to use this tool to patch the executable (*.exe file) of the software you want to have these additional GB’s of virtual memory.

You can download the tool from this website.
It can be used by clicking on it and choosing the file or through command line (e.g.: “4gb_patch file.exe”).
It automatically creates a backup copy of the original executable.

A modified fsx.exe (SP2) is available upon request via our download page.

Resources: MSDN, NTCORE.com