Jim Young

If MT6 has an AFCAD in the area in the MyTraffic/Scenery folder you can disable it in the MyTraffic/Scenery folder but most of the crashes have been caused by the MyTrafficmil.bgl which can be disabled (and those crashes usually cause an ntdll.dll error). Most likely static aircraft on a military base. But the fastest and easiest way to see if MT6 is at fault is to disable MT6 in the scenery.cfg and fly one flight w/o AI. You have the latest hotfix 3 to P3Dv3.4 and I recall that fixed a problem with Nvidia SLI configurations. But, MT6 has a lot of really, really old AFCAD's developed even in the FS9 days and earlier (as early as 2005). The g3d.dll error is very frustrating but it is important to know it does come with P3DV3.4 and LM might have changed something that is no longer compatible in older programs.

I saw on another forum where this problem was fixed by rebuilding the fsx.cfg. Try renaming fsx.cfg to fsx.cfg.off, restart and the fsx.cfg will be rebuilt. The uiautomationcore.dll is part of a dotnet package and Microsoft.net's are used by developers of their products (i.e., add-ons to FSX), to manage and run their application properly. If there is an add-on that is not compatible with FSX and you have a module being loaded at startup, then FSX will not work and the uiautomationcore.dll error will be thrown. I still think it is an incompatible uiautomationcore.dll in your main FSX folder (is that the one used by FSX-SE?? If so, it will not work in FSX (boxed)).

It is sad and tragic these things happen. I too pass on my thoughts and prayers for the families and friends of those who were killed or injured by this senseless attack. Justice will be served.

The AVSIM CTD Guide has a link to the proper one too.

The recommended version of the uiautomationcore.dll in your main fsx folder is 16386 (page 28, AVSIM CTD Guide). Your version is 16397.

If I get a crash consistently in the same location, I use Process Monitor to see what was loading at the time of the crash (page 17, AVSIM CTD Guide).

The one setting in the same folder as the P3D.cfg is the old default but some addon programs still use it. Only the one in the same folder as the scenery.cfg will rebuild to the default. You do not need the modules to test P3D and see if a module is crashing it. Your addons, like PMDG, will still run and you won't even notice the module is not running.

When I arrive at an airport I just hit Ctrl+F12 and select deboarding or just airport services. The program will prompt you as to what to do and what doors to open. It does not automatically generate ground services. You have to enable it through Ctrl+F12. If I'm departing an airport, I make sure the engines are off and then do a Ctrl+F12 and request pushback (it won't do it with the engines running). That is extremely accurate at FSDT airports as the pushback places you exactly, 100% on the taxi line. There is a manual that comes with the product. Mine is located in C:\Program Files (x86)\Addon Manager\Couatl\GSX.

Last Sunday, the Wash DC area had a massive storm coming up from the South. Decided to take a flight in it from Wash Dulles to Charlotte NC (right in the red stuff!). Loaded everything and then the apphang and crash. I have had the CMeteo module being loaded for a long time with no problems. It was just because of the heavy weather that it decided to cause problems. Perhaps the module could not handle heavy weather? The other factor was that I had ASP4 loaded too. If I did not load ASP4, I had no problems with the CMeteo module. So I originally thought it was ASP4 but got to thinking that many members use ASP4 with P3DV4 with no problems. I decided to disable the two dll.xml's and that solved the problem. No more crashes. After 3 days of trying to find out what was going on, it was a major relief when I found the culprit.

We have received reports and I think this topic is rapidly going off topic and becoming inciting for many. Topic closed.

You have a configuration, an addon, and/or, most likely, a module not compatible with P3DV4. Application hangs are very difficult to fix. In fact, your report shows nothing of value as it does not show the signature for the crash (which is the usual case for most AppHangs). I had one the other day and it took me some time (only 3 days) to figure it out. Sim would freeze (hang) and then crash to desktop. In my case it was the CMeteoXmlx64.dll, a module in your main P3D Folder used by Carenado for weather. It is not needed but, if you fly into heavy weather, after that, you will almost always get hangs/crashes. If you have this module (and I know you do) being loaded in one of your dll.xml's, disable it. In fact, whenever you get a hang or crash, one of the first things you should do is to disable both of your dll.xml's. The one located in the same folder as your scenery.cfg will be rebuilt. Another module that causes crashes or hangs is the fsuipc.dll. If not up-to-date I have seen where it may cause a problem. Not on every use of P3DV4 but it does cause a hang or crash if not up-to-date.

The AVSIM CTD Guide, page 35, has several probable solutions to the infamous ntdll.dll error.

The uiautomationcore.dll does not fix any crashes involving moving the mouse to the Addon Menu item. If anything, it will fix a crash if you right click with the mouse on the aircraft panel at least 19 times ( I have yet to replicate this but this is what the experts have told me). The uiautomationcore.dll is probably the biggest placebo every developed for any game on the Internet. I can understand the concept though. The uiautomationcore.dll comes with the Microsoft.net packages. FSX was built with Microsoft.net 1.1 and the uiautomationcore.dll everyone wants you to throw into the main folder of FSX is the one that came with the original Microsoft.net. Microsoft.net's are not, for the most part, backward compatible (Google this for more information if you want). I think there is a module being loaded that is causing your problem. It's like a memory leak. You load the module and it is leaking and causing you to have problems using the FSX menu. I would recommend renaming your dll.xml to dll.xml.off and see if this fixes the problem. If not, I would then delete or rename my fsx.cfg to fsx.cfg.off, restart FSX and it will be rebuilt. Lots of other suggestions in the AVSIM CTD Guide.

The g3d.dll will rear its ugly head if there is something incompatible in the area of the crash, say, a texture on the ground or aircraft texture. The g3d.dll is impossible to diagnose. Years ago, after the release of FSX/Acceleration, everyone was getting the g3d.dll error. We had many very knowledgeable members trying to figure out the cause. A solution was never found after 100's of pages of attempts in a g3d CTD topic here on AVSIM. The developer of FSUIPC came up with a solution to "trap" the error so FSX would not crash. I understand he did not do the same for P3D or FSX-SE as he believed the developer's had fixed the problem (FSX could never be further updated and the programming that existed in 2006 still exists today). I got a g3d error in P3dV4 while attempting to land at Orbx KSAN, runway 9. The error occurred 100% of the time in the same location off the Calif shoreline near the approach for ILS9. As I recall, it was caused by Orbx KSAN as it did not occur with LatinVFR KSAN. So, I suspect it was an object or texture that was loading that caused the error. Bottom line: there is no fix for this crash. You will have to investigate by removing scenery in the area of the crash and hopefully you will find a solution.

Never heard of it but looked it up and it looks really simple - https://www.python.org/