actually I found that making my fs9.exe file 'large address aware' had no impact on frame rates at all......all it did was put an end to random crashes/freezes/and CTDs that would happen to me if I had too many things going on at once.......and these would usually occur in a busy area, and then like the straw that breaks the camels back something simple like tuning an ILS or VOR, or making a radio call, or reconfiguring your aircraft for landing would be that one process too many and...........your flight is over.

Sound familiar?

It sounded familiar to me when the OP was still part of this thread.....and it kinda sounds familiar when you brought up your experiences.

Hmmm, could be....I am going to have to re-activate that BWI and see if it freezes just at that same point, regardless of whether I change ATC frequencies or not.  I have looked into the memory patch since reading about it here, though I am running Win-7 64 bit, and from what I'm seeing, I don't know if it applies to the 64 bit version Win-7 or just the 32-bit.....but I am always interested in seeing if "more is better".....and I always make backups so I can undo as necessary.   One note I saw in another forum somewhere, I do check my task manager, and have never seen FS using more than 800,000 to 900,000 of memory (885,000 is about the most I've seen, even when it freezes), even at the most-dense locations, it's usually at about 550,000....and I do check to see that FS is using both cores, as I know sometimes you need to "trick" it into using both, but that's a whole other topic....Still more to ponder and fiddle with, but isn't that the fun of it? (unless it's crashing your machine, of course)......... 

 

= = = = = = = = = = = = = = = = = = = = = = =

Steve Kareta

FS2004 / AS6 / UT / one-zillion add-ons  //  Win-7-64 Dell Dual-core / 4 Gb ram / Palit-NVidia Geforce GTX-460-1gb

 

 

One note I saw in another forum somewhere, I do check my task manager, and have never seen FS using more than 800,000 to 900,000 of memory (885,000 is about the most I've seen, even when it freezes), even at the most-dense locations, it's usually at about 550,000

 

Which means you are not running out of memory........ever.

Hmmm, could be....I am going to have to re-activate that BWI and see if it freezes just at that same point, regardless of whether I change ATC frequencies or not.  I have looked into the memory patch since reading about it here, though I am running Win-7 64 bit, and from what I'm seeing, I don't know if it applies to the 64 bit version Win-7 or just the 32-bit.....but I am always interested in seeing if "more is better".....and I always make backups so I can undo as necessary.   One note I saw in another forum somewhere, I do check my task manager, and have never seen FS using more than 800,000 to 900,000 of memory (885,000 is about the most I've seen, even when it freezes), even at the most-dense locations, it's usually at about 550,000....and I do check to see that FS is using both cores, as I know sometimes you need to "trick" it into using both, but that's a whole other topic....Still more to ponder and fiddle with, but isn't that the fun of it? (unless it's crashing your machine, of course)......... 

 

= = = = = = = = = = = = = = = = = = = = = = =

Steve Kareta

FS2004 / AS6 / UT / one-zillion add-ons  //  Win-7-64 Dell Dual-core / 4 Gb ram / Palit-NVidia Geforce GTX-460-1gb

Hi Steve,

Actually, I think the term "memory patch" is a source of confusion, as it has nothing, absolutely nothing, to do with how much memory you have on board or the amount of memory FS is actually using at the time the issue occurs. That said, it is as applicable to 64 bit systems as it is to 32 bit systems.  All it does is make it so that FS can use a wider array of memory addresses.  Because you're on a 64 bit operating system, you only need to make FS aware of the additional addresses available to it.  It's very simple to do, takes maybe all of two minutes, and will do absolutely no harm to your system or to your FS installation.  I've detailed the procedure in this post:

 

http://forum.avsim.net/topic/429619-fs9-crashes-right-before-a-landing/?p=2885381

 

Read through the thread to see some additional explanation.  This is a process that is known to fix a number of issues similar to what you are experiencing.  If you've gone through the steps to troubleshoot the problem and nothing has fixed it yet, this is absolutely a good fix to try. As I said earlier, this will do absolutely no harm to your system or to your FS installation, when done according to the steps I outlined in the other post.

Let us know how you make out.

 

Cheers,

Jeff

I once had a similar problem in this area which was a CTD at KDCA and a freeze up at KIAD.  I had ImagineSim KIAD and Cloud9 KDCA installed along with FSGenesis mesh.  

 

After much trial and error I removed Cloud9 UT_LWM1_VTPH.BGL from its terrain scenery folder and it resolved a conflict with the FSGenesis mesh. The CTD and freeze up issues were eliminated.  fyi

 

I once had a similar problem in this area which was a CTD at KDCA and a freeze up at KIAD.  I had ImagineSim KIAD and Cloud9 KDCA installed along with FSGenesis mesh.  

 

After much trial and error I removed Cloud9 UT_LWM1_VTPH.BGL from its terrain scenery folder and it resolved a conflict with the FSGenesis mesh. The CTD and freeze up issues were eliminated.  fyi

 

 

99.9% of the time it's a bad bgl or texture file that's causing the freeze or crash issue. modifying the FS9.exe will not fix it because it's not a memory issue or a address aware problem. Common sense trouble shooting is all that's needed.

99.9% of the time it's a bad bgl or texture file that's causing the freeze or crash issue. modifying the FS9.exe will not fix it because it's not a memory issue or a address aware problem. Common sense trouble shooting is all that's needed.

You may well be right.  You may also be wrong.  I've seen this problem countless times over the years and it has been resolved by this process. Now, I am willing to concede that I may be equally wrong, but to say definitively that "it's not a memory issue or a address aware problem." is a disservice to the person trying to resolve the issue. Regardless of how the problem manifests itself, be it an OOM, a freeze, black screen or CTD, any or all of which are symptomatic of the problem, is not of any real significance. The compelling factors are that it is reproducible in the same general area, every time, and very often regardless of the aircraft being used.  Since it is reasonable to conclude that there is no way anyone can say with 100% certainty what is or is not the problem, it is equally reasonable to suggest all courses of action to resolve the issue.  No two systems are the same.  Neither are any two FS installations the same. There are just too many variables involved, most of which may or may not be known only to the person sitting in front of the system.  And as we're talking about common sense troubleshooting, and given that the person with the problem has exhausted the most obvious troubleshooting methods, I'd rather try the approach that I (and others) have advocated, which takes all of two minutes and has exactly zero negative implications as to the operation and function of the system and the program, than to spend hours or days going through every BGL file in a package, one by one.  Particularly when it may not be a single file that is causing the issue, but may in fact be an issue caused by several files collectively.  Setting the proper flag in the FS9 executable is at least worth trying, if for no other reason than to rule out the memory address issue being the culprit.  While Steve seems to have fixed his problem, I still can't get my head around why so many people want to knock this approach.  It has been used to resolve a number of issues for quite a while now, and advocated by many people, including some far more knowledgeable than I.  And I've yet to see a single negative issue come from it's use.  My recommendation of this process is based on sound theoretical and empirical evidence garnered over many years.  Until such time as someone can produce satisfactory evidence contrary to its' validity, I will continue to vehemently advocate for its' use.  Not necessarily as a first step, but as part of the troubleshooting process.  And if it doesn't solve the problem, the user is absolutely no worse off for the attempt as, again, it does nothing to negatively impact operation of the system or the program.  I've been doing this as long as anyone here, so take it for whatever that's worth to you.

 

Regards,

Jeff

 

Edit:  My apologies to you Bill, as this was not personal and certainly not directed specifically towards you.  I know you've been around for a long time too.  Unfortunately, you were just a straw on the back of a much larger camel, and I offer my sincerest apologies for singling you out.

Cheers,

Jeff

Jim....I have thus far (luckily) never had my FS CTD, nor have I seen any memory error or OOM messages, with this rig.  Whew....why did I just say that (?!?!?!?)...  Jinxed for sure now.   Just this current freeze thing.

 

Jeff......Yes, I have a bit of a grasp on that, I just used the phrase "Memory Patch" here for brevity.  I'm always a fan of making the program run a bit better/smoother...so I did go ahead and download the Explorer Suite and applied the >2Gb mod to my FS9.exe....   I have not yet flown it enough to see if it makes any difference in frames or smoothness, but like I said earlier, I really didn't have any frame/stutter issues before (except for this freeze outside IAD), so it may be hard to see any gain, unless it's pretty significant.

 

Steve0616......I found that specific file (Cloud9 UT_LWM1_VTPH.BGL) in my DCA terrain/scenery folder.......what is it, a C9/UT compatibility file (guessing by the name)?   I did have time to do the flight out of IAD this morning, and with BWI disabled, everything was fine, so now I'll try activating BWI and removing that file and see if that does it.

 

Fun, fun, fun...

 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =

Steve Kareta

FS2004 / AS6 / UT / one-zillion add-ons  //  Win-7-64 Dell Dual-core / 4 Gb ram / Palit-NVidia Geforce GTX-460-1gb

I guess it is a UT compatible file. 

 

Its been a few years now since I had this problem.  All I can remember is that it seemed like the CTD and freezing problems started after I installed the FSGenesis payware mesh, so that was a hint.  There may have been some other (freeware) DC related scenery that I also deleted...I just can't remember now. I do not remember having BWI issues, but I may have never checked there. gl

Hi There,

 

I recently was suffering CTDs on flights from KBOS to EDDF and noticed that the CTD happened at the same location in Canada (ie) very close to Deer Lake Airport CYDF. I had an freeware addon for this airport. Anyhow I used Scenery Config Mgr to disable (not delete) all my Canadian Scenery and tried the flight again with the same aircraft and active sky. No problem the flight went all the way to Frankfurt without a problem.  I then went back into the Scenery Config Mgr and re-enabled all the Canada scenery except for the Deer Lake addon. Restarted FS to get the scenery reset and tried the flight again. No problem the flight went perfectly well. I tried another long haul in a totally different part of the world (Macau to Auckland) and all went well.  If you have the Deer Lake Addon try disabling it and see if that helps.. You may have some other freeware issue but this one was my problem..

 

By the way I have used the 4gb patch on my fs9.exe, my active sky, fsbuild etc without any problem. I also run the FS9 using the 8 core tool which seems to spread the processor load.

 

Rgds, John

 

 

Jeff......Yes, I have a bit of a grasp on that, I just used the phrase "Memory Patch" here for brevity. I'm always a fan of making the program run a bit better/smoother...so I did go ahead and download the Explorer Suite and applied the >2Gb mod to my FS9.exe.... I have not yet flown it enough to see if it makes any difference in frames or smoothness, but like I said earlier, I really didn't have any frame/stutter issues before (except for this freeze outside IAD), so it may be hard to see any gain, unless it's pretty significant.

 

Thanks Steve.  I doubt that you'll see any improvement as far as frame rates or stutters, you actually shouldn't notice anything, except that you should not run into any future problems with unexplained, repetitive crashes and freezes.   Glad you got it sorted,

 

Cheers,

Jeff

 

 

 

Nicely said Jeff....But I don't think you are the one who should be apologizing......The arrogant and dismissive tone from a few of the members involved in this thread have been really.......un-acceptable, un-necessary, and clearly uninformed. Just because you haven't encountered this specific problem with your install it doesn't mean that it doesn't exist.......regardless of how long you have been a member of Avsim

 

Edit

the quote is supposed to be Jeff's post to Bill.......but it refuses to work   :rolleyes:

Right - but the memory patch, however useful it may be, is probably quite frankly off topic for the CTDs mentioned by the OP in this topic. My frustration with this thread was that a sensible diagnostic method that I have used frequently to good effect (including last night) was simply ignored at best - and ridiculed for no good reason by some.

In the event, the CTD the OP is experiencing seems not to be a classic OOM, if that is what it is - the OP reports no error messages. In my experience, a classic memory-leak caused OOM will cause FS to exit with an error message stating that there is no more available memory for FS to use. I know - I saw it at least 30 times last night (there was a bad traffic file in my install that was causing FS to OOM on load. And all my mesh for Seattle got corrupted at the same time, so I tracked down that CTD, too - made for a hairy night, chasing two independent errors.) It also appears to be based on time of day or direction of flight. This, to me, indicates either a bad texture or landclass file or a problem with an AI aircraft - neither problem of which the 4Gb patch will address - and the nature of the problem is easily determined by noting at which point in the load process the sim OOMs or CTDs.