SteveFx

You presumably had my dx10 fixer installed. The manual explains that if you want to move a fsx installation which uses the fixer that you must uninstall the libraries using the dx10 controller before moving the fsx installation and then reinstall the libraries after the move. Not following this process will cause fsx to crash as you describe. The fixer is not working on your laptop, if you want it to work you must install the fixer and then install its libraries.

Fastspring have introduced new charges which make continuing to sell the fixer uneconomic. I therefore intend to remove the product from sale at the end of March (2024).

It’s your windows documents folder. C:\users\{your name}\documents.

I believe that bufferpools has no impact if running dx10.

If it’s isn’t dx10 preview then turn on missing texture alert in fsx.cfg to find out what the issue is. https://www.fsdeveloper.com/forum/threads/missing-textures.7376/

I’m glad that it’s sorted and I am particularly glad that it wasn’t the fixer!

That’s disappointing, there is nothing else that I can suggest. From the ctd forum this problem originated with a windows update. From what I have seen that seems to generate a spurious event that api.dll cannot handle. In my testing switching to ipv4 seems to greatly reduce the incidence ( ie I haven’t seen it since ) but if you have had a further occurrence then the “fix” cannot be 100%.

If it doesn’t work in dx9 then it is an Active sky issue relating to firewall or perhaps a missing texture. All you have to do to test this is press the switch to dx9 button in the fixer controller. If it works in dx9 but doesn’t work in dx10 without the fixer libraries then it clearly isn’t a fixer issue but must be an ASN issue relating to the base dx10 shaders or the different handling of missing texture in dx10 vs dx9. Note that in dx10 without the fixer rain works but looks bad. if it works in dx9, works ( albeit badly) in dx10 and works in dx10 with the fixer libraries installed and the rain shader unticked in controller file->debug then it’s a conflict between active sky shader changes and the fixer. I think that’s unlikely mind. If test 1 or 2 suggests that a missing texture could be the issue then you need to Google fsx.cfg missing texture alert to find instructions eg here for instance. https://www.fsdeveloper.com/wiki/index.php/Missing_textures The most likely explanation is something firewall related, but if you test as I suggest you can narrow it down.

Also read this one

Is this windows 11? I believe that AS16 and ActiveSkyNext don’t work at all on windows 11. I believe that there is a patch for AS16. If it isn’t windows 11 then does it work in dx9 ( your post isn’t clear)? does it work in dx10 with fixer libraries uninstalled? does it work in dx10 with fixer libraries installed but rain fix disabled. is there a missing texture? - enable missing texture alert in fsx.cfg. based on the answers I suspect that your best approach may be to raise a support ticket at hifi simulations but I will look at what you report back.

I have investigated this issue and can report some findings. I believe that the crash requires a SIMconnect client to trigger it. I think that (possibly because of the mentioned Windows Update) something subtle has changed in the behaviour of named pipes causing FSX to get a spurious event that it fails to handle properly. My suggestion of a possible workaround ( I am uncertain how well this will work) is therefore to force the use of IPv4 for SimConnect. With Acceleration or FSX-SE that is as simple as placing the following 3 line simconnect.cfg in your Documents folder. [SimConnect] Protocol=IPv4 Address=127.0.0.1 Do NOT add a "Port=" line. With SP2 you need to follow the SDK manual (which is wrong for FSX-SE and acceleration) and additionally craft a simconnect.xml which goes in the same location as your fsx.cfg file. For SP2 the IPv4 entries in the two files must contain a "Port=" and they must be the same port. The fsx function that crashes at 3afa2 (Acceleration) or 1ddc (Steam) can be identified as a fileiocompletion callback (ie async IO). It appears to be used just for reading commands via SimConnect - although it could have other uses that I have not seen. The callback receives three parameters - an errorcode, the number of bytes read and a pointer to some "context" setup by FSX earlier. In normal operation it is called when a SimConnect command is received with an errorcode of zero, the length of the command and the "context". When a SimConnect client disconnects it is called with an error of 8000014B aka NT_STATUS_PIPE_BROKEN. In the failure case it seems to get an errorcode of zero, zero bytes read, but the real issue is that the "context" pointer is not correct. The function crashes trying to call a object in the context which isn't there.

Can you try creating a simconnect.cfg file in your Documents folder containing the following 3 lines [SimConnect] Protocol=IPv4 Address=127.0.0.1 Ignore the SDK documentation about this file which is slightly wrong for acceleration and FSX_SE. Do not add a "Port=" line as it suggests. That should switch any simconnect users to use IP rather than a named pipe. Let me know if that reduces or eliminates the problem (or makes absolutely no difference)! The location in API.dll where your system is crashing is in an callback function that appears to be exclusively used by SimConnect. I have a theory that the crash occurs if a simconnect user closes the session whilst FSX is trying to send it a message. I know this because I had crashes at the same location and did some investigation on it. I think that the buffering that TCP/IP uses may make the problem less likely than with named pipes. Note: if this does help then ideally we should try and find which simconnect user disconnects during startup and try to switch it to IPv4 rather than switching everyone. I also don’t know if fsx supports IPv4 for DLLs loaded via dll.xml., it may ignore the setting for these as they part of the same process.

Are you using a weather engine, if so which one?

You might do better posting on the aerosoft forums or the main avsim fsx forum rather than a backwater support forum. https://forum.aerosoft.com/index.php?/topic/105600-mega-airport-heathrow-fsx-has-run-out-of-graphics-memory/ if you want to fly with the combination of 1) complex detailed aircraft model 2) very detailed airport then you need to make some compromises with the fsx sliders, dialling down ai traffic and ground traffic to a few percent and setting lod range to default perhaps. When you find something that works then try moving them up a little at a time. if you don’t want to make those compromises then you need to look at a 64 bit simulator such as msfs 2020 or P3D. in choosing Heathrow X you have probably chosen the absolute worst case of the latter. London is a large city surrounded by many airports and thus some care is needed. Try reading some of the reviews for Heathrow X on sim market, you are not alone in having this issue and there is no great solution https://secure.simmarket.com/aerosoft-mega-airport-london-heathrow-xtended-fsxp3dv2-(download).phtml

I can’t help but think that you are posting in the wrong forum.