Yep, patched. I was using my Captainsim 767.

 

Page file is fixed at 8192 MB on a separate drive.

 

I may disable all my addons, and do this Atlantic flight in the stock 747 with Orbx enabled and also with it disabled.

 

Metroliner; Fokker 27 in my case.

 

I had it set to "System Managed" and set it to 8192 last night.

I've also updated my video drivers (344.60 -> 347.09), because why not.

 

Couldn't test it yet though.

 

And I take that your maximum texture resolution is set to the default of 4096 in the fsx.cfg?

 

 

 

Respectfully, that's totally incorrect.  If you read the AVSIM interview with the developer of FSX-SE, he states there was nothing changed in the FSX engine.  Nothing.  They just got it to work inside Steam.  That's it.

 

They've recompiled it for the Visual Studio 2013 runtimes, which does make a difference as the runtimes control interaction with the lower levels of the operating system and, subsequently, drivers and hardware. That's why a lot of users got slight performance and VAS management improvements after they've installed FSX:SE because MS improved Visual Studio capabilities over the years.

On the other hand, the more modern VS runtimes could provoke incompatibility .

 

And we're trying to figure out a common denominator here to see what can be done to work around said instability. That these are isolated cases makes this a bit baffling though. The g3d crashes in FSXMS were much more common, but on the other hand did not occur as often after FSUIPC was installed.

 

This thread was never about OOMs. In fact, I can't even remember when I got one the last time.

 

 

This thread was never about OOMs. In fact, I can't even remember when I got one the last time.

 

Sorry for hi-jacking your topic.

 

Best regards,

Sorry for hi-jacking your topic

 

Don't worry about it.

 

If, by some miracle, you find a workaround or the cure for the issue, feel free to highjack it as you please.

But please don't move it from one forum to the next and back again. I'm still dizzy from the last time.

The plot thickens...

 

Did a test flight with the Metro from somewhere in ND. Had suspiciously little autogen. Saved the flight and quit FSX.

Went into the fsx.cfg and saw that I still had SmallPartRejectRadius=1 in there.

The line comes from Bojote's tweak utilities, but the value is custom.

Commented out the line. Started FSX. Wouldn't even load the flight; crashed with the usual g3d error before reaching 100%.

Reenabled the parameter and set it to its default value (4?). Boom, g3d. Set it to 5, just for fun. Guess what...g3d.

Set it back to "1". The flight loads.

 

I'm mildly confused.

 

 

- Edit:

Threw out "ALLOW_SHADER_30=1" (from Bojote's Shader 3.0 Fix). Flight loads, but ugly black lines between the tiles.

Then let the shader cache rebuild. G3d crash.

 

I've just deleted the "ShadersHLSL" folder and let Steam redownload it. (This is great for rebuilding broken files, by the way. Just delete the files, run Steams "Verify integrity" function for FSXSE and it will download the missing files without replacing any files you've altered, e.g. the texture.cfg or so.)

Will also rebuild the shader cache and the fsx.cfg for good measure.

 

 

- Edit²:

Rebuilt the cache and fsx.cfg. G3d crash.

*Applauds wildly*

 

Rebuilt the shader cache again. No crash.

 

(The "ugly black lines" are the annoyingly straight roads in the Midwest. *Ahem*)

 

 

- Edit4:

 

I can now reliably reproduce the crash. Happens at 88% (AI Aircraft territory).

 

Working over Process Monitor output ATM.

The plot thickens...

 

Did a test flight with the Metro from somewhere in ND. Had suspiciously little autogen. Saved the flight and quit FSX.

Went into the fsx.cfg and saw that I still had SmallPartRejectRadius=1 in there.

The line comes from Bojote's tweak utilities, but the value is custom.

Commented out the line. Started FSX. Wouldn't even load the flight; crashed with the usual g3d error before reaching 100%.

Reenabled the parameter and set it to its default value (4?). Boom, g3d. Set it to 5, just for fun. Guess what...g3d.

Set it back to "1". The flight loads.

 

I'm mildly confused.

 

 

- Edit:

Threw out "ALLOW_SHADER_30=1" (from Bojote's Shader 3.0 Fix). Flight loads, but ugly black lines between the tiles.

Then let the shader cache rebuild. G3d crash.

 

I've just deleted the "ShadersHLSL" folder and let Steam redownload it. (This is great for rebuilding broken files, by the way. Just delete the files, run Steams "Verify integrity" function for FSXSE and it will download the missing files without replacing any files you've altered, e.g. the texture.cfg or so.)

Will also rebuild the shader cache and the fsx.cfg for good measure.

 

 

- Edit²:

Rebuilt the cache and fsx.cfg. G3d crash.

*Applauds wildly*

 

Rebuilt the shader cache again. No crash.

 

(The "ugly black lines" are the annoyingly straight roads in the Midwest. *Ahem*)

 

 

- Edit4:

 

I can now reliably reproduce the crash. Happens at 88% (AI Aircraft territory).

 

Working over Process Monitor output ATM.

 

AI huh.........interesting. Thanks for sharing.

Next update. Went after the dependencies for FSX and things have improved (I think).

 

1. Uninstalled:

- MSXML 4 Parser (all installed versions)

- Visual C++ Redistributables (all versions that were installed)

- Net Framework (all versions that were installed)

 

2. Rebooted.

3. Installed:

- MSXML 4.0 SP3 Parser

- Visual C++ 2005 SP1 Redistributable (both x86 and x64)

- Visual C++ 2008 SP1 Redistributable (both x86 and x64)

- Visual C++ 2010 SP1 Redistributable (both x86 and x64)

- Visual C++ 2012 Update 4 Redistributable (both x86 and x64)

- Visual C++ 2013 Redistributable (both x86 and x64)

- Net Framework 4.5.2

 

4. Rebooted.

5. Ran Windows Update and let it install the security updates for the XML Parser, Net Framework and C++ Redistributables.

6. Rebooted.

7. Installed:

- [FSXSE folder]\_CommonRedist\DirectX\Jun2010*

- [FSXSE folder]\_CommonRedist\DirectX\vcredist\2005**

8. Rebooted.

 

So far, i could start my "bad" flight thrice in a row without a single crash.

 

Fingers crossed...

 

 

*This installed some files that I thought I already had, so my money is on DirectX as a potential fix.

(Installing DirectX is also the fix for the TinMouse's sound module, by the way, so...)

** For good measure.

Cool! I guess it is safe to uninstall dependencies like that?

Cool! I guess it is safe to uninstall dependencies like that?

 

At worst, some programs (including FSX) will refuse to run.

 

 

- Edit:

The minimal and least risky attempt at a solution would be installing DirectX from the folder within FSXSE. You can't break anything with that.

 

 

 

 

 

- Edit²:

It's back. F****** H***!

Which airport in ND are you flying from? Maybe I can recreate the crash.

Jamestown (KJMS) and then due west (270-ish).

 

 

 

New development:

 

If there is a crash, it was always related to a certain AI aircraft model (at least according to ProcessMonitor).

The textures look okay, but opening the model in ModelConverterX makes it crash, which should not happen.

I must have screwed up somewhere during the conversion into FSX native format.

 

If the model is indeed the cause, it would at least explain the seemingly "random" nature of the crashes.

 

 

- Edit:

Hmmmm. Reconverted the model and didn't get a crash so far. The AI part of the loading process is slightly quicker as well.

(Must. Not. Jinx. It...)

 

 

 

 

If you want to bug hunting yourself:

- Download Process Monitor from here: http://technet.microsoft.com/en-us/sysinternals/bb896645

- Launch ProcMon.exe

- In the filter popup (if you don't get one, press CTRL+L or use the filter icon in the toolbar), add the following filters:

1. "Process" "Is" "fsx.exe" then "Include"

2. "Result" "Is" "Success" then "Exclude"

- Go fly

- During longer sessions, you might have to clear the log with "Edit" -> "Clear" or CTRL+X

- If you get a crash, it must have something to do with the file(s) mentioned in the last few lines of the log

Approaching two hours of chugging along in the Metro and no crash so far. ^_^

Could this be solved after all?!

Performance also seems to be better than ever...

 

 

Now that I think of it, I have already seen a g3d crash in FS9(!) that was caused by a wrongly formatted (or corrupted) panel texture. So the g3d error might just be related to models (apparently as in my case) or textures.

 

 

 

Here's some more food for thought.

I might put this and all the other, general stuff I've written here into an all-in-one post later on and mark it as "best answer" so others won't have to dig around this thread for info.

 

 

General considerations:

- Try to make the crash as reproducible as possible

- FSX loads airports and AI traffic in a 100nm "bubble" around your aircraft. If you get a crash, try to remember the position at which it happened and see if you have any add-on scenery installed in that radius. Won't work that reliably for AI traffic though as there tends to be a lot of different planes in the air, more often than not at a different location after you reload FSX (that's sadly how the AI engine works).

- Peek into Window's event log*. "Windows Logs -> Application" should contain the FSX crash event as an "Error" near the top. Check the "General" tab and the exception code. "0xc0000005" means "Access Denied", which is the first indication that a file couldn't be read.

- Let ProcessMonitor run alongside FSX as described above. It will get you nearer to the source of the crash. The folder containing the last file that could not be processed is an indicator for the location of the "bad file". The file itself could also be the bad one, but don't take that for granted!

- If the folder containing the source of the crash is an aircraft folder, use ModelConverterX** to check if the .mdl files are okay. They're not okay if MCX crashes while opening them. For the textures, see the next point.

- If the source of the crash seems to be a scenery, try to open a .bgl file that seems to be a library (either because of its filesize or because it's named "Somethingsomething_Lib" or "Lib_SomethingSomething") in ModelConverterX. You can browse through the models contained in the library in MCX. Do this until you find a "bad" one or until you've inspected them all. For textures used in sceneries, you'll have to use Imagetool*** or DXTBMP**** to read those that are not in 32bit format. If Imagetool refuses to open a texture, try DXTBMP, but keep in mind that any texture that can't be opened in Imagetool is a likely candidate for the source of the problem.

 

Should you find a broken model or texture file, reinstall the add-on it belonged to and then test again to rule out errors during installation. If the error persists, contact the developer and tell him what file(s) might have caused the crashe in your case.

 

 

Regarding Terrain.dll crashes:

Duplicate AFX files are a likely cause for this. Use this tool to scan for duplicates:

http://www.scruffyduck.org.uk/files/airport_scanner_08.zip

 

 

 

*How to: http://www.sevenforums.com/tutorials/226084-event-viewer-open-use-windows-7-a.html

**http://www.scenerydesign.org/development-releases/

***in SDK\Environment Kit\Terrain SDK

****http://www.mwgfx.co.uk/programs/dxtbmp.htm

Hmm, OK. I have a lot of World of AI traffic installed, so maybe it is a bad plane.

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. ^_^

 

 

 

Hmm, OK. I have a lot of World of AI traffic installed, so maybe it is a bad plane.

 

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.

I'm getting consistent repeatable g3d.dll CTD's always with the Exception code 0xc0000005 and Exception Offset of 0x00077e65.  

 

While it happens anyway after 10-20 mins of flight, seemingly anywhere in the UK (i'm running ORBX England)  I can force it to happen by opening a second view panel on AI traffic and using a key to cycle through the AI aircraft fairly quickly.   

 

Oddly, if i run process monitor two things happen:  

 

   EZDOK closes and cannot be restarted again until I restart the computer

   The same CTD cannot then be reproduced, although i will occasionally get StackHash module CTD's instead.

 

At no point has VAS been an issue, always plenty available when the crash happens.

 

Strange.....

Try again without EZDOK, cycle through AI aircraft and then check ProcessMonitor.