I get this (inaccurate) message sometimes, like just now flying happily from KSEA to CYVR. I thought it was a thing of the past: my PC has certainly not run out of memory - my O/S is Windows 7 x64 with 16GBs of RAM installed. My desktop CPU usage meter showed that there are still well over 11GBs of physical RAM free at the time FS9 crashed and the page file (I have it set to 1024MBs fixed - partly to stop it resizing itself on my SSDs) shows 0% usage. I would increase the page file, but as it is hardly ever even used, what would be the point?

 

I have also read that this error message can be generated by a corrupt page file; but I have also read that this only applies to Windows XP, not Win7 and later. Anyone know differently?

 

Nothing at all related to the cause of the crash in Event Viewer (just the consequences of it).

 

This error is usually (in my experience) generated by a faulty scenery file (bgl/bmp). I wonder if anyone has had this "OoM" problem in the area in which I was flying and could indicate what might be amiss.

 

Thanks,

 

Martin

That message is generally displayed when you have run out of VAS (Virtual Address Space). That is not the same as RAM. It's strange to hear of someone getting an OOM in FS2004, but that message was all too familiar to me when I used FSX and P3D v2!

Thanks.

 

What exactly is VAS then? (Well, I see what it is from Googling, but what is the relevance here to FS9?). No, not the same as RAM, I know,and not the same as virtual memory (page file) either. How and why would I 'run out' of it.. and can this be fixed?

 

I started up my flight to Vancouver again from the same spot, with AutoSave, and it is running OK for now. So perhaps (though not conclusive) it's not a scenery file problem on this occasion.

I get this (inaccurate) message sometimes, like just now flying happily from KSEA to CYVR. I thought it was a thing of the past: my PC has certainly not run out of memory - my O/S is Windows 7 x64 with 16GBs of RAM installed. My desktop CPU usage meter showed that there are still well over 11GBs of physical RAM free at the time FS9 crashed and the page file (I have it set to 1024MBs fixed - partly to stop it resizing itself on my SSDs) shows 0% usage. I would increase the page file, but as it is hardly ever even used, what would be the point?

 

I have also read that this error message can be generated by a corrupt page file; but I have also read that this only applies to Windows XP, not Win7 and later. Anyone know differently?

 

Nothing at all related to the cause of the crash in Event Viewer (just the consequences of it).

 

This error is usually (in my experience) generated by a faulty scenery file (bgl/bmp). I wonder if anyone has had this "OoM" problem in the area in which I was flying and could indicate what might be amiss.

 

Thanks,

 

Martin

Wow  I had  this  all  the time  when I flew  to cyvr  from  ksea   always  the same  spot was  a orbox  bgl  file  that was  the culpit   found  what it  was  and  removed   the 2  offending  files  and  no more ooms..  But   they  should  have  fixed  this with  the latest   patches.  So if  your  crashing  at the same  spot  all the time   as  I was  than it  the scenery  issue

I would allow Windows to manage the page file size just in case, FS2004 does use it. On my Windows 7 x64 Ultimate, Windows has allocated a minimum of 12mb, recommended 12283mb, currently using 8189mb on my 1tb HD, and I've never had an OOM crash.

Ok.. here's what the message means: The application (in this case FS9) tried to allocate memory for use and was denied the allocation. When the OS does not allow an application to allocate memory, you get an OOM. FS9 can only access around 3gb of memory, so if something is chewing that up via allocations (bad scenery BGL, etc)... it is going to get the error sooner or later. It's not a page file issue, it's not a physical RAM issue, it's not a hard drive space issue.

Thanks for the replies. I knew it wasn't anything to do with physical memory and 95% sure it was nothing to do with pages memory either (and 100% certain it had nothing to do with disc space!). My fs9.exe is the /3GB patched version, BTW.

 

As I mentioned, I have usually been able to cure these problems (fortunately rare) by locating the faulty bgl or bmp file and removing it, but that is a long process as it is often by trial and error, and is especially frustrating when the crash is intermittent and cannot be reproduced every time you fly the same route.

 

I am very pleased to get some specific advice therefore! Thank you Pete, but which file was the culprit? What is an 'orbox' bgl file? I have no files called 'orbox' anything in my FS9 setup, bgl or otherwise. Which scenery/update were you talking about?

 

Hope you folks have a good Christmas meanwhile...

 

M.

<p>Rerunning the flight, another CTD as I was descending on the glidescope, CYVR Rwy8L. Certainly 'felt' like a bgl error (having had so many over the past 12 years, each CTD has a kind of feel to it!)...

 

</p>
<p> </p>
<p>Problem signature:<br />
  Problem Event Name:    APPCRASH<br />
  Application Name:    FS9.EXE<br />
  Application Version:    9.1.0.40901<br />
  Application Timestamp:    4135a208<br />
  Fault Module Name:    d3d9.dll<br />
  Fault Module Version:    6.1.7601.17514<br />
  Fault Module Timestamp:    4ce7b7b3<br />
  Exception Code:    c0000005<br />
  Exception Offset:    00034706<br />
  OS Version:    6.1.7601.2.1.0.768.3<br />
  Locale ID:    2057</p>
<p> </p>

<p>Sometimes seems to me these days that completing a flight with no errors is the exception rather than the norm!</p>

Even AVSIM has 'crashed' now! What's all that code doing there?

 

Problem signature:
  Problem Event Name:    APPCRASH
  Application Name:    FS9.EXE
  Application Version:    9.1.0.40901
  Application Timestamp:    4135a208
  Fault Module Name:    d3d9.dll
  Fault Module Version:    6.1.7601.17514
  Fault Module Timestamp:    4ce7b7b3
  Exception Code:    c0000005
  Exception Offset:    00034706
  OS Version:    6.1.7601.2.1.0.768.3
  Locale ID:    2057

Different error - it's in the DirectX code. May be a bad video driver or texture.

 

FWIW, if you have a 64-bit OS it may make sense to set the LARGE_ADDRESS_AWARE bit on your FS9.EXE file - it will allow it to get a full 4GB of memory instead of 2GB.

 

Cheers!

Luke

My exe file is patched, as I mentioned above. Thanks.

<p>Rerunning the flight, another CTD as I was descending on the glidescope, CYVR Rwy8L. Certainly 'felt' like a bgl error (having had so many over the past 12 years, each CTD has a kind of feel to it!)...

 

 

Are you running Vancouver Plus, by chance?  I used to have to run the texture configurator to resolve CTD issues in that area.  fwiw.

CYVR Vancouver International Version 1.0 by Jonathan Gabbert (AVSIM library) for the airport (about the only one out there of any real substance of course).

 

I don't have Vancouver Plus, no. I only really fly in and out of CYVR, IFR, never around the area, so probably not worth it (It is on sale on SimMarket for a bargain price though, if anyone thinks it's a 'must have', even so! The reviews there are amazingly good). 'Part 2' includes the airport, it says, but since this 'part 1' scenery is now so old (2005?) I suppose the project was abandoned? If the two were available together I'd probably go for it...

 

Whatever, have to look elsewhere for the CTDs..

My exe file is patched, as I mentioned above. Thanks.

 

Apologies, I missed that. It's unfortunate that with FS you really need to install addons one at a time to ensure you can rollback if one is a little wonky. Scenery is especially challenging.

Cheers!

Luke

I had such issues too, and they were due to some bad scenery files. So before waiste time or invest in other sceneries, try to deactivate all your sceneries and check whether you still have the same issue at the specific Position with your "virigin" FS. If not, you reactivate the sceneries steps by steps (about 20 at once) until you get the issue again. Finally you might be able to localize the responible scenery and the file. Needless to say that you should backup your scenery.cfg before starting deactivation. For this kind of handing I use FS Scenery Manager as it's very easy and fast to handle.

 

Bernard