Almost every CTD has the exception code 005, Memory Access Violation. It really means nothing. The G3D CTD was a common crash in FSX back 3 or 4 years ago. It was fixed by the developer of FSUIPC who set up a program to trap the error so FSX would not crash. It was known as the worst CTD in the history of FSX. We had hundreds looking for a solution and none could ever be found. Most of the crashes were in the Orbx FTX area as that was popular at the time. I still say there is a problem with a texture or static aircraft in that area but the FSUIPC utility traps 99.9% of all FSX G3D errors.

 

I understand the FSUIPC developer is going to make his utility compatible with FSX-SE (may have been done already).

 

StackHashes are discussed in the AVSIM CTD Guide. They are hard to diagnose but I found that the 5.4c version of MyTrafficX causes this crash because of an AI schedule. I have since gone back to the 5.4b version and I use only the default schedule that came with the program (not any on the developer's website). It has fixed this problem. StackHashes can also be caused by bad BIOS settings, wrong voltages, etc. The CTD Guide shows all the probable causes. I'm positive that FSX-SE would have the same probable fixes as FSX/P3D as the sims are all alike.

 

VAS only comes into play if you have a long flight but you are having your crashes every 10-20 minutes so it would be impossible for you to have a VAS issue.

 

Has the Orbx scenery been blessed yet for FSX-SE? My understanding is that new registry entries have to be made. If they are not there, then crash. Same goes with EZDOK and any other addon that has not been fixed to work with FSX-SE.

 

FSX uses Microsoft Visual C++2005 w/SP1 for proper installation of that software plus Acceleration. I understand FSX-SE uses the 2012 or 2013 version but, if you are going to add addons that were made back with FSX was first developed, you will need Microsoft Visual 2005 w/SP1 and Microsoft Visual 2008 w/SP1. Most people who have FSX installed already have these Visuals installed. Those who just have FSX-SE installed may not and then try to install a product that used Microsoft Visual 2008.

 

You also need Microsoft.Net 2.0 and maybe 3.0 and 3.5 too. Do not know what FSX-SE uses but old FSX products/addons need those dotnets. Microsoft.net packages are used by developers to make sure their product runs as intended to include memory management via the uiautomationcore.dll (part of each dotnet package).

 

So, my advice, if you have any addons to FSX-SE, you would be wise to uninstall them until an official installer is developed for the product(s).

 

Best regards,

Just finished the transcon with a greaser at MFR. No hiccups apart from the odd stuttering due to weather updates.

I even had FSX run in the background for hours at a time while I was surfing. No complaints from the program.

 

 

 

Almost every CTD has the exception code 005, Memory Access Violation. It really means nothing. The G3D CTD was a common crash in FSX back 3 or 4 years ago. It was fixed by the developer of FSUIPC who set up a program to trap the error so FSX would not crash. It was known as the worst CTD in the history of FSX. We had hundreds looking for a solution and none could ever be found. Most of the crashes were in the Orbx FTX area as that was popular at the time. I still say there is a problem with a texture or static aircraft in that area but the FSUIPC utility traps 99.9% of all FSX G3D errors.

 

I understand the FSUIPC developer is going to make his utility compatible with FSX-SE (may have been done already).

You may be right regarding the model and texture in an ORBX release, but Pete Dowson already said that my error signature is completely different from the one he fixed back in the day. See here:

http://forum.simflight.com/topic/78338-fsxse-g3ddll-error-is-back/?p=474853

 

 

StackHashes are discussed in the AVSIM CTD Guide. They are hard to diagnose but I found that the 5.4c version of MyTrafficX causes this crash because of an AI schedule. I have since gone back to the 5.4b version and I use only the default schedule that came with the program (not any on the developer's website). It has fixed this problem. StackHashes can also be caused by bad BIOS settings, wrong voltages, etc. The CTD Guide shows all the probable causes. I'm positive that FSX-SE would have the same probable fixes as FSX/P3D as the sims are all alike.

I've skimmed over the guide and took a closer looks at the sections similar to what I've written before.

 

1. The section about Process Monitor filters should include the "if result is success then exclude" filter as this will greatly reduce the amount of data that is logged. The stuff that does not work is the most interesting.

 

2. The section with g3d.dll should include a mention of a possibly corrupted model or texture as the culprit.

 

3. The terrain.dll crash can also be caused by duplicate AFX files. Might be worth noting in the document as well.

 

VAS only comes into play if you have a long flight but you are having your crashes every 10-20 minutes so it would be impossible for you to have a VAS issue.

The faulting module for OOM crashes is entirely different (api.dll).

 

You also need Microsoft.Net 2.0 and maybe 3.0 and 3.5 too. Do not know what FSX-SE uses but old FSX products/addons need those dotnets. Microsoft.net packages are used by developers to make sure their product runs as intended to include memory management via the uiautomationcore.dll (part of each dotnet package).

The redistibutable for .NET Framework 4.5 includes all earlier versions.

he redistibutable for .NET Framework 4.5 includes all earlier versions.

Microsoft.net versions are NOT backward compatible. Do a Google search for "are Microsoft.net versions backward compatible" and you'll quickly see they are not. You need the old ones for old applications. Personally I wish you were right.

 

The faulting module for OOM crashes is entirely different (api.dll).

Very good. You are exactly correct. Please look at the probable causes for the api.dll crash in the AVSIM CTD Guide.

 

I'll leave the process monitor description and setup as is. I have tested it personally and this is how I was able to find that one of the MyTrafficX AI schedules was the cause of freezes, StackHash and NTDLL.dll errors. Only AI was loading when FSX froze up. I disabled MyTrafficX in the Scenery Library and all my problems were solved.

 

It is not known exactly what causes the g3d.dll error so this is why anything about corrupted textures or missing objects were left out. I can say that this was definitely investigated by the hundred's of members who attempted to find a solution to this problem. FS Developer has entries you can place in your fsx.cfg that will freeze fsx when it finds a missing texture or object. I use to have it in the guide but it got to be very confusing as everyone thinks that if a texture or object is missing, that's the cause of the crash. Most developers leave textures and objects out on purpose, especially FTX/Orbx. If there was a problem with the FTX/Orbx missing textures or objects, everyone who owns the product would be seeing the crash. They are not. The g3d.dll may be corrupted or not fully compatible with old programs like FSX/Acceleration. P3D has never seen this problem (yet)(that I know of). It was developed much later than FSX/Acceleration.

 

I have not seen where the terrain.dll crash can be caused by duplicate AFX files. I have done extensive searches and this was never discussed. Duplicate AFX files may be required as each software program calls files to be loaded and, if they are not in the required folder, there may be a problem. Not sure if it would cause a crash. It's just that the texture/objects would not be loaded.

 

The biggest issue I have found recently for many problems is a bad AI schedule. Evidently AI aircraft are trying to follow a schedule and, if the aircraft required for that schedule cannot be found, FSX will crash or freeze. But this only happens in certain areas as all AI around the world are not generated when you load a flight. Just the AI in your AO. So this is why we do not see everyone getting this crash.

 

Thanks for your suggestions.

 

Best regards,

Flying a 737-200 out of NYC (the single most AI infested place in North America) at the moment. One hour in, no crashes so far. ^_^

 

 

 

 

Considering that you could always reproduce the crash near a geographic location (Greenland), checking scenery first might be useful.

Doesn't ORBX have Greenland as their demo area or so? Any other sceneries that you have installed in that area?

 

 

 

 

- Edit:

 

Crossing over into Missouri at the moment. The only thing that has crashed so far is Process Monitor, due to log file overload.

 

Well, I took an F-18 and flew all over Greenland, but I couldn't make it crash. Weird. Seems to only crash when I'm four hours into a transatlantic flight!

 

I may do another flight tomorrow, transatlantic, and look at my logs when it eventually crashes

Microsoft.net versions are NOT backward compatible. Do a Google search for "are Microsoft.net versions backward compatible" and you'll quickly see they are not. You need the old ones for old applications. Personally I wish you were right.

Microsoft says:

"The .NET Framework 4.5 and its point releases are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5. However, by default, apps run on the version of the common language runtime for which they were developed, so you may have to provide a configuration file to enable your app to run on the .NET Framework 4.5. For more information, see the Version compatibility for apps section earlier in this article. "

http://msdn.microsoft.com/en-us/library/ff602939(v=vs.110).aspx

 

 

It is not known exactly what causes the g3d.dll error so this is why anything about corrupted textures or missing objects were left out. I can say that this was definitely investigated by the hundred's of members who attempted to find a solution to this problem. FS Developer has entries you can place in your fsx.cfg that will freeze fsx when it finds a missing texture or object. I use to have it in the guide but it got to be very confusing as everyone thinks that if a texture or object is missing, that's the cause of the crash. Most developers leave textures and objects out on purpose, especially FTX/Orbx. If there was a problem with the FTX/Orbx missing textures or objects, everyone who owns the product would be seeing the crash. They are not. The g3d.dll may be corrupted or not fully compatible with old programs like FSX/Acceleration. P3D has never seen this problem (yet)(that I know of). It was developed much later than FSX/Acceleration.

MSFS does indeed not crash if it encounters a missing texture. It will simply render the object in question in black (DX9) or with the colors of the main menu background (DX10).

 

 

I have not seen where the terrain.dll crash can be caused by duplicate AFX files. I have done extensive searches and this was never discussed. Duplicate AFX files may be required as each software program calls files to be loaded and, if they are not in the required folder, there may be a problem. Not sure if it would cause a crash. It's just that the texture/objects would not be loaded.

You're right. After a bit of searching, I couldn't find any evidence for a link between terrain.dll crashes and duplicate AFCADs. It probably was another module then, but still...scanning for duplicates should be done as part of the investigation looking for the source of the crash.

According to virtuali, terrain.dll crashes stem from corrupted (i.e. unreadable) terrain datafiles (mesh, vector, landclass).

See: http://www.fsdreamteam.com/forum/index.php?PHPSESSID=f9ru2kjk4341agbo5rl21kutl0&topic=3541.msg31082#msg31082

 

The biggest issue I have found recently for many problems is a bad AI schedule. Evidently AI aircraft are trying to follow a schedule and, if the aircraft required for that schedule cannot be found, FSX will crash or freeze. But this only happens in certain areas as all AI around the world are not generated when you load a flight. Just the AI in your AO. So this is why we do not see everyone getting this crash.

TBH, I doubt that. If MSFS can't find an AI model in a flightplan, it will simply not render that model.

I don't know what ultimately made the flight plan from that MyTraffic update go bad, but it does appear to have been unreadable at one or more location(s) in the flight plan file if it made FSX crash.

 

After converting flight plans from FS9 into FSX format, I've had the problem of AI aircraft never leaving their gates. The solution was converting the flight plans again with another tool. So even if I had "broken" plans, they did not make FSX crash.

Flying a 737-200 out of NYC (the single most AI infested place in North America) at the moment. One hour in, no crashes so far. ^_^

 

 

 

 

Considering that you could always reproduce the crash near a geographic location (Greenland), checking scenery first might be useful.

Doesn't ORBX have Greenland as their demo area or so? Any other sceneries that you have installed in that area?

 

 

 

 

- Edit:

 

Crossing over into Missouri at the moment. The only thing that has crashed so far is Process Monitor, due to log file overload.

 

No, Iceland is the demo area I believe.

 

I got the CTD again at the southern tip of Greenland. AI aircraft were disabled.

 

Last log in Process Monitor:

 

E:\Steam\steamapps\common\FSX\Scenery\World\texture\325b2an1.agn NAME NOT FOUND

 

However, I have a bunch of these errors well before the CTD in the log.

No, Iceland is the demo area I believe.

 

I got the CTD again at the southern tip of Greenland. AI aircraft were disabled.

 

Last log in Process Monitor:

 

E:\Steam\steamapps\common\FSX\Scenery\World\texture\325b2an1.agn NAME NOT FOUND

 

However, I have a bunch of these errors well before the CTD in the log.

I wonder if this could be a problem specifically with Vector 1.20? I use it, and I believe that you do as well?

 

One of Vector's main functions, in addition to providing overlays of roads, bridges, railways etc, is to give high-resolution definition to the perimeters of water bodies, and coastlines.

 

Needless to say, the coastline of Greenland is extremely rugged, with many nooks, crannies, inlets and headlands. Perhaps an invalid numeric field or fields exists in A Vector coastline data file in this area.

 

I've logged several 4+ hour flights in SE over the continental US, coast-to-coast and north-to-south, and so far, the area just south of Greenland is the ONLY place where I have had a terrain.dll crash (yet!)

I wonder if this could be a problem specifically with Vector 1.20? I use it, and I believe that you do as well?

 

One of Vector's main functions, in addition to providing overlays of roads, bridges, railways etc, is to give high-resolution definition to the perimeters of water bodies, and coastlines.

 

Needless to say, the coastline of Greenland is extremely rugged, with many nooks, crannies, inlets and headlands. Perhaps an invalid numeric field or fields exists in A Vector coastline data file in this area.

 

I've logged several 4+ hour flights in SE over the continental US, coast-to-coast and north-to-south, and so far, the area just south of Greenland is the ONLY place where I have had a terrain.dll crash (yet!)

 

Same here with FSX only crashing near southern Greenland. Yet, I try to reproduce it by flying over all over southern Greenland with an F-18, but FSX only CTD when I'm flying an airliner of some sort originating elsewhere.

 

I looked up that last filename, and indeed 325b2an1.agn is an ORBX file.

 

EDIT: Yes, I do use Vector 1.20.

Same here with FSX only crashing near southern Greenland. Yet, I try to reproduce it by flying over all over southern Greenland with an F-18, but FSX only CTD when I'm flying an airliner of some sort originating elsewhere.

 

I looked up that last filename, and indeed 325b2an1.agn is an ORBX file.

 

EDIT: Yes, I do use Vector 1.20.

 

I saved the flight plan that I was using on my previous flight that crashed, (which was using the PMDG MD-11) - perhaps I'll try it again, following the exact same flightpath between the same waypoints.

 

The original flight originated at EGSS and I was just about 4 hours in when I had the crash. Rather than waste 4 hours re-flying to the Greenland coast from Stansted, I think I'll start the flight at BIKF, which is much closer. If THAT goes without problems, then I'll try the full original flight from EGSS again.

 

I think I have even saved the FSGRW weather download from the first flight...

I looked up that last filename, and indeed 325b2an1.agn is an ORBX file.

 

EDIT: Yes, I do use Vector 1.20.

There was another thread running here recently relating to a possible fix for VAS exhaustion caused by a memory leak. One post had a link to a French flight sim site which had an article about this very issue... multiple "file not found" errors relating to both ORBX and UTX files with a *.AGN extension.

 

Apparently FSX and SE both look for these files in the default \world\scenery folder, when they actually live in one of the ORBX or UTX custom scenery folders.

 

Apparently the "fix" was to use a couple of external utility programs - one to identify all of the AGN files that FSX can't find, and another to auto-create symbolic links to place in the default \world\scenery folder pointing at their actual locations.

 

Supposedly the missing files did not lead to FSX crashes, but rather a lot of unnecessary CPU load, disk accesses and (possibly) VAS depletion.

Microsoft says:

"The .NET Framework 4.5 and its point releases are backward-compatible with apps that were built with earlier versions of the .NET Framework. In other words, apps and components built with previous versions will work without modification on the .NET Framework 4.5. However, by default, apps run on the version of the common language runtime for which they were developed, so you may have to provide a configuration file to enable your app to run on the .NET Framework 4.5. For more information, see the Version compatibility for apps section earlier in this article. "

http://msdn.microsof...(v=vs.110).aspx

In the AVSIM CTD Guide we state the following: "You can verify whether your versions are properly installed and up-to-date by using the .Net Framework Setup Verification Tool User's Guide. Microsoft.net packages are used by developers to make sure the program runs in the way they intended, including memory management. The packages are, for the most part, not backward compatible."

 

Whenever anyone is have a CTD or freeze or another issue with FSX, it is important that you look at making sure you have all of the components required to run the product without any problems.  Since the proper dotnet package is installed with FSX and each addon (if not already found on your system), it would be a mistake to remove any of the old packages.  Like Microsoft Visuals, you need the old ones for old programs.

 

Best regards,

In the AVSIM CTD Guide we state the following: "You can verify whether your versions are properly installed and up-to-date by using the .Net Framework Setup Verification Tool User's Guide. Microsoft.net packages are used by developers to make sure the program runs in the way they intended, including memory management. The packages are, for the most part, not backward compatible."

 

Whenever anyone is have a CTD or freeze or another issue with FSX, it is important that you look at making sure you have all of the components required to run the product without any problems.  Since the proper dotnet package is installed with FSX and each addon (if not already found on your system), it would be a mistake to remove any of the old packages.  Like Microsoft Visuals, you need the old ones for old programs.

 

*Sigh*

 

Whatever you say.

Apparently the "fix" was to use a couple of external utility programs - one to identify all of the AGN files that FSX can't find, and another to auto-create symbolic links to place in the default \world\scenery folder pointing at their actual locations.

 

Supposedly the missing files did not lead to FSX crashes, but rather a lot of unnecessary CPU load, disk accesses and (possibly) VAS depletion.

 

I was curious about this, so I made a batch file that would symlink .agn files to the scenery/world/texture folder, but then I realized the ORBX .agn files are not all unique. Only about 70% share the same filename with another file among the 5,500 total .agn files.

Got a terrain.dll crash half an hour ago while loading a flight. Did the ProcessMonitor dance. Identified yet another broken AI model als the culprit. Re-converted the model from the FS9 one with ModelConverterX. Problem solved.

Nice! Glad you're figuring these things out quickly.

i was plagued by g3d crashes in FSX-SE recently, and found an easily repeatable case that only took around 10-15minutes to test. (EDTE EXMOR UN864 SUBUK ESKDO EGPH)

 

i started making changes and eliminating addons to see if i could catch something that was causing it but was surpised that the solution presented itself by accident. one of the things i noticed was that some of the textures over the orbx wales region were corrupt looking, which was odd because this was a fresh install. in searching for a solution to that i found a thread that explained the region files need to be ABOVE the orbx LC for europe files in the scenery setup. 

 

moving all those above (and also the orbx library files to the top) not only fixed the corruption but it eliminated my g3d crashes as well. i supposed it was a coincidence that i hadn't quite noticed that they were all happening when i had the 'Europe' region enabled in ftx central, i just thought it was random and i had happened to be flying around there frequently because i got some of those regions over the holidays.

 

anyway another thing i noticed is that switching to hybrid mode will slide them under the OpenLC files,but switching back to europe again will leave them there in the wrong spot, thus requiring manual intervention in the scenery library again. not sure if i don't have my insertion point setup correctly or if this is an installer bug. 

 

anyway i noticed someone else mentioning orbx england was causing them problems so maybe something similar was happening there, and a lot of y'all seem to be flying in the north atlantic so perhaps it's distantly related. i'll continue to investigate but i'm crash-free on my last 4 flights so i'm optimistic for the moment. 

 

(addons used are: pilots ftx mesh, ftx vector,global, europeLC, and the various UK regions. when i get some time to do more flights i'll be checking the norcal/pnw regions out although if the culprit is a LC/region conflict of some sort it may not be relevant there since there's no custom LC there..)

 

anyway cheers and good luck

-andy crosby