I'm a little concerned about your last sentence though. You have the 32 bit uiautomationcore.dll from Vista installed don't you?

 

The source OS was 64 bit, yes (I've been running nothing but 64 bit desktop systems since Vista), but the dll is 32. If I recall correctly, it's the one in the SysWOW64 folder, not the one in System32. Yeah, I know - seems intuitively backwards but on a 64 bit system, the System32 folder is where the 64 bit dll's live.

 

Scott

You should have the Vista 32 bit version of the uiautomationcore.dll in your main FSX folder. You should do nothing whatsoever to the Windows 7 editions. With the dll in your main FSX folder, it will get loaded whenever you run FSX instead of the one in your system32 and SysWOW64 folders.

 

Best regards,

Jim

You should have the Vista 32 bit version of the uiautomationcore.dll in your main FSX folder. You should do nothing whatsoever to the Windows 7 editions. With the dll in your main FSX folder, it will get loaded whenever you run FSX instead of the one in your system32 and SysWOW64 folders.

 

Yes, Jim I understand that completely. Sorry if that wasn't clear. The above was only in reference to your question about where the correct 32 bit Vista version I used came from, NOT where I put it.

 

Scott

Cool. Thanks Scott.

 

Best regards,

Jim

Finally got time to read your post, w6kd.

 

Scarlett--appreciate that you took the time to do this, but there are some material errors that need addressing here.

 

 

 

No, first of all I think you mean the 0xC0000005 exception, which is the dreaded MEMORY_ACCESS_VIOLATION. It has nothing to do with file access--it means that a program has attempted to access memory at an address that is not allowed. The most common causes on a stable PC are null or otherwise bad pointer references, memory buffer overruns, and other programming issues. Often a program works but does not gracefully handle bad data when it appears--MSFS's unruly behavior when a bad texture is encountered is but one of too many examples. An unstable overclock or some bad RAM can also cause this by corrupting a memory address being loaded into a CPU address register. But the memory exception violation is usually a programming and/or bad data issue, or a sign of system instability--but not a file system fault at all.

 

I agree with all of these points. However a MEMORY_ACCESS_VIOLATION can very well occur if FSX calls for a "File", and cannot find it. Had it happen before.

 

Now the CRASH DLL can vary, but the exception code will stay the same!

I strongly disagree that crashes in this, or any other MS kernel or library module "usually" indicate an installation error. Usually NOT. The significance of the faulting module is purely identification of the module containing the instruction that tripped the fault. Often--usually, in fact--an error with the MC Visual C++ runtime identified as the faulting module is caused by another program passing out-of-bounds or nonsensical parameters to one of the functions in the library. I can easily write code to cause a crash in a particular library module outside of my own program by calling one of its library functions with a null/bad pointer, for example. The aforementioned Airbus X Extended had/has easily duplicated bugs that will cause a memory exception in MSVCRT80.dll in a perfectly good installation. I don't want to see people spring-loaded to messing around with their operating system when this error occurs, because there is a lot of potential to cause greater harm when they do--especially when following the advice of some of the snake-oil solutions floating like landmines out in the internet wilderness (like manually tinkering with Windows side-by-side libraries, for example).

 

I agree, but in order to troubleshoot problems with the MSVCR80.DLL, a routine check is to RE-INSTALL the libraries. The crash very well COULD be caused by faulty parameters in code such as the airbus X extended, but the very first thing to do, in order to solve the CTD, would be to routinely re-install the runtimes.

 

I think it is more likely caused by a corrupt scenery bgl or texture than a missing one--FSX can and does handle missing textures without crashing. There's an fsx.cfg setting that'll display a label where every missing texture is encountered, in fact--if you enable it you might be surprised how many textures are missing in your day-to-day operations. You can also trigger a fault in this or another dll if you set Bufferpools to 0 and then overrun the video frame buffer by sending data faster than the video card can process it, i.e. having the sliders set too high. But that kind of crash isn't caused simply by setting sliders too high--it's caused by first intentionally defeating FSX's designed video buffer management process (BP=0) and then overwhelming it. If you take a stock FSX install and max every slider, you may only get 3 fps, but it won't CTD.

 

Well there's lots of things you can do to the config to make a CTD occur. And a CORRUPT scenery bgl is basically a "missing" BGL because FSX cannot read it. And you can very well cause a CTD by turing sliders too high. You can cause way MORE. The CTD may not be "Directly" related to the sliders, but NTDLL.DLL is the most common sign of an overstressed computer. Not always the case, but turning down sliders fixes many CTD for many people.

 

----

 

And again, I will say again with the UIautomationcore.dll, that this file, and the "Menu Crashes" are all SYSTEM SPECIFIC.

Well there's lots of things you can do to the config to make a CTD occur. And a CORRUPT scenery bgl is basically a "missing" BGL because FSX cannot read it. And you can very well cause a CTD by turing sliders too high. You can cause way MORE. The CTD may not be "Directly" related to the sliders, but NTDLL.DLL is the most common sign of an overstressed computer. Not always the case, but turning down sliders fixes many CTD for many people.

 

 

No, a corrupt scenery bgl is not the same as a missing one. Loading nonsense data from a corrupted file can cause buffer overruns, index out-of-range issues, and other unhappy things. A missing add-on scenery bgl is often properly handled by FSX without crashing, and if it does fault because it can't find a file, it should be an orderly shutdown by FSX' error-handling rather than a crash due to a memory access violation.

 

An untweaked install of FSX on a stable PC will not CTD, even with sliders maxxed. But if you start messing with the safety mechanisms (e.g. the Bufferpools=0 setting, which removes CPU-intensive but fault-tolerant video frame buffering from the video rendering process) you can induce a CTD with the combination of taking out the built-in safeguards and then overrunning the unprotected subsystems in a way the software designers did not intend. I would say that NTDLL.dll faults are symptoms of an *unstable* PC, not necessarily an "overstressed" one. Bad drivers, failing components, and unruly driver-level software interactions (e.g. third-party dll hooks into video drivers such as the ENB series) can cause these sorts of errors on a PC even when running at design specs.

 

And again, I will say again with the UIautomationcore.dll, that this file, and the "Menu Crashes" are all SYSTEM SPECIFIC.

 

All crashes are system specific. I have been able to easily reproduce the UIAutomationCore-related menu crashes on at least three new Win 7 + virgin FSX builds, though. And a local copy of the Vista version of the DLL with which FSX was designed fixed it in every case.

 

Regards

No, a corrupt scenery bgl is not the same as a missing one. Loading nonsense data from a corrupted file can cause buffer overruns, index out-of-range issues, and other unhappy things. A missing add-on scenery bgl is often properly handled by FSX without crashing, and if it does fault because it can't find a file, it should be an orderly shutdown by FSX' error-handling rather than a crash due to a memory access violation.

 

 

Sweet, well learned something new!

 

An untweaked install of FSX on a stable PC will not CTD, even with sliders maxxed. But if you start messing with the safety mechanisms (e.g. the Bufferpools=0 setting, which removes CPU-intensive but fault-tolerant video frame buffering from the video rendering process) you can induce a CTD with the combination of taking out the built-in safeguards and then overrunning the unprotected subsystems in a way the software designers did not intend. I would say that NTDLL.dll faults are symptoms of an *unstable* PC, not necessarily an "overstressed" one. Bad drivers, failing components, and unruly driver-level software interactions (e.g. third-party dll hooks into video drivers such as the ENB series) can cause these sorts of errors on a PC even when running at design specs

 

Nope, not every case. My previous computer, which was made by the computer company and came windows 7-pre-installed, had a vanilla install of FSX, and my crashes went away with sliders turned down. Nothing added on, and nothing changed in the config.

 

All crashes are system specific. I have been able to easily reproduce the UIAutomationCore-related menu crashes on at least three new Win 7 + virgin FSX builds, though. And a local copy of the Vista version of the DLL with which FSX was designed fixed it in every case.

Yes, but I was talking about UIAUTOMATIONCORE.DLL. Me and Jim have tried to re-produce this "Menu crash" by accessing the menu over 30 times, unable to reproduce the crash. There is something *clearly* different about me and jim's setup. This is why as a routine check we tell people to remove it from the folder.

Nope, not every case. My previous computer, which was made by the computer company and came windows 7-pre-installed, had a vanilla install of FSX, and my crashes went away with sliders turned down. Nothing added on, and nothing changed in the config.

 

Agree! Max settings only compound the likihood of a CTD with poorly written software or a badly configured BIOS, and/or improperly installed drivers.

 

Regarding the uiautomationcore.dll fix - I have tried several times to replicate this ctd. The only odd thing between my setup (and maybe Scarlett's) is the fact I have no pre-fsx software installed. Only pure FSX addons. I have not heard of anyone fixing a crash with the old uiautomationcore.dll with a vanilla FSX/Acceleration. I think the uiautomationcore.dll fix is a placebo for many as a lot of problems with fsx are fixed simply by turning your system off and restarting it. Plus the uiautomationcore.dll helps dotnet manage memory and perhaps there's an issue there with those who are fixing their systems with the uiautomationcore.dll from an old operating system. It's not worth arguing over though. If it works for some that's great! It's amazing though that a Google search will show only FSX has this problem even though every game published uses the uiautomationcore.dll.

 

Best regards,

Jim

Hi, 

 

I found this topic very useful, I was having crashes but turned out they were related to my SweetFX... ahhh. I wish ENB was compatible with FSX..