Newbie Alert: FSX APPCRASH | UIautomationCore.dll

[SmallJet]

FSX Appcrash with UIautomationCore.dll

I know what it is like trying to get up to speed on code that was half-baked, unfinished and now discontinued. I also know that FSX is the only viable solution that meets my particular needs at this time. And, I've quickly learned that you have to accept the limitations of FSX, which are both born of incomplete source code and operating system incompatibility in more than a few places. However, if you search far enough you can typically find answers to many frustrating problems.

Problem:

When a module blows its top and pukes all over FSX (forcing it to shut down), this is what the dump typically looks like:

Problem signature:
Problem Event Name: APPCRASH
Application Name: fsx.exe
Application Version: 10.0.61472.0
Application Timestamp: 475e17d3
Fault Module Name: uiautomationcore.dll
Fault Module Version: 7.0.0.0
Fault Module Timestamp: 4a5bdb1d
Exception Code: c0000005
Exception Offset: 0000e52a
OS Version: 6.1.7601.2.1.0.768.3
Locale ID: 1033


Potential Solution for Windows 7:

There have been many suggestions offered and many more tried. Most people come back and report that the "fix" did not last for very long. Some suggest the deletion of a windows system .dll file, which I do not suggest. This problem seems to vary with internal OS configuration from Vista, to XP to Win7 - either under 32bit or 64bit modes.

Two things to note for Windows 7. There are actually two (2) uiautomationcore.dll files. One located in C:\Windows\System32, and the other located in C:\Windows\SysWOW64. The appcrash dump does not tell you what to do with the .dll file, nor does it tell you which file you need to use to provide the fix to FSX.

On my box, the fix came when I copied the 32bit version of uiautomationcore.dll from the C:\Windows\System32 path, into the root install directory of FSX, which should be C:\Program Files (x86)\Microsoft Games\Microsoft Flight (provided you accepted the default install path during initial installation of FSX).

After moving the 32bit version of this file (uiautomationcore.dll) to the FSX install root, there have been no AppCrash dumps of any kind on my box.

Though FSX does run in 64bit mode, its source code was not originally developed for the 64bit operating system and may have a conflict with the 64bit version of uiautomationcore.dll. Whether this is true or not, I don't know. Whether FSX calls the 64bit, or whether one of the 64bit capable "add-on" components ends up calling the 64bit automation file, I also do not know for sure. But, I do know that somewhere along the line, during a flight simulation using a third-party (non-native) aircraft add-on, that FSX ends up attempting to use the automation file - probably the 64bit version. Why FSX cannot locate the 32bit version on its own, or if the third-party Add-On forces the issue by using the 64bit version instead of the 32bit version, is again something that I do not fully know.

What I do know, is that supplying the FSX installation environment (its root install path) with the 32bit version, solves the UIautomationCore.dll appcrash problem on my box. Your results may vary.

Note:

Move, edit, delete, cut, paste, and/or alter any operating system level dynamic link library (.dll) file at your own risk.

[SmallJet]

It looks like this was already addressed here: APPCRASH A-FATAL-ERROR-OCCURED-FSX-DONE.

Distinctions:

1) I don't know about the source/origin of the uiautomationcore.dll being used in the suggested zip file.
2) I don't know if the 32bit or 64bit version of the automation file was used in the suggested zip file.

Could be one and the same - you'll have to try it and find out.

[aputech]

Yeah, definitely a persistent and recurring problem that has been addressed here ad-infinitum and will probably continue. Some people never have problems with it--I didn't until I'd already been running FSX trouble-free for a few years, and then just a few months ago (after a routine Windows (7) update), I got my first uiautomationcore crash. Strangely enough, my other laptop hasn't had a Windows update in about a year and it's been running FSX for a year straight, no crashes. But, each person's situation is unique, so no "cure all" remedy exists as far as I can tell.

Let us know what you find, if possible; sometimes a fresh mind is the best thing to solve an old problem. Be advised, however, that many "fixes" thus far that have seemed to have solved the FSX crashing problem actually hadn't; the problem would reoccur unexpectedly days, weeks, or even months hence.

Aputech

[fxsttcb]

If you search the forums you'll find umpteen fixes for uiautomationcore.dll as the "Faulting Module".
There are two known good Early Vista files that when placed in the FSX root folder may work.
Version 6.0.6001.18000 or Version 6.0.5840.16386

I have been running FSX for years with 6.0.6001.18000 and no errors.
Lately I've been getting them. GRRRRR!!. Neither Version is working. I am not using any new addons.
My FSX is Same 'ol-Same 'ol, so, I assume that a recent Windows Update is the culprit.

One of the folks had found that removing/renaming the file in Windows\System32 also cured the issue.
I took ownership of it and created a batch file to rename it and launch FSX, then when FSX is closed it renames it back to default.
ATM, I'm in the process of testing that...Don

[SmallJet]

I've seen many windows core automation posts listing one-off solutions - most of them resulting in a return of the same problem for the end-user.

I've done a small amount of study on this problem (not having a large amount of time to dedicate to it) and I've come to the conclusion that the crash is definitely a run-time event within the shared-code container (file) itself. All of the aircraft model add-ons run as "additional code" added to the FSX file system. None of them run as independent .exe programs requiring either high or low level API calls between FSX. The uiautomationcore.dll is a mask that ensures compatibility between .Net user interface clients running in support of the Windows Presentation Foundation environment. Essentially, uiautomationcore.dll is a single source mapper for dissimilar frameworks that have different UI implementations.

The uiautomationcore.dll is supposed to handle dialogue between both uiautomation providers (API in .dll form) and uiautomation clients (API in .dll form). I don't know what the exact implementation of uiautomationcore.dll looks like for FSX, but I now believe this to be a .Net issue at the potential source of the problem. Think about it. FSX users who report using the software for eons, all of a sudden have problems with uiautomationcore.dll after running a Windows Update, which they had not run for a long time. Well, the .Net Framework is in a perpetual state of "fixing" at Microsoft and continually gets updated through the Windows Update Service. It is possible that the uiautomationcore.dll is getting tweaked by various Windows Updates, [b]without any updates to either uiautomation providers (API in .dll form) and uiautomation clients.[/quote] This could easily explain why there has never been any "official" fix for this problem. Microsoft can control its UIautomationCore, but it has no control over how third-party developers write to their respective Providers and Clients.

While Microsoft does not list any .Net requirements to run FSX under Windows 5, Windows 6 or Windows 7, it does still communicate with components from the .Net Framework, namely UIAutomationCore.dll. I ran a search on my Windows 7 OS, looking for:

UIAutomationProvider.dll
UIAutomationClient.dll

I found them sitting under: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\v3.0. So, I start scratching my head again. I then found this from another FSX user:



An Unhandled Exception in the .Net Framework. This user was using FSX on a Windows 7/64bit box and had both SimConnect and REX version 2 installed and running (circa 2010). So, I start scratching my head even more, as I realize that FSX was initially released during the reign of .Net Framework 2. Aces Studios, ran development for FSX from 2006/2009. Most Windows 7 boxes out there have already been updated to .Net Framework 4.0, which was originally cut loose in April, 2010. Therefore, FSX is behind the .Net Framework power curve and has no ability to ever gain ground. The .Net Framework 4.5 was released last year, putting FSX even further behind the power curve.

Windows 7, does include .Net Framework 2.0. That's a fact. The problem is that any application that uses the old .Net Framework 2.0x, must be able to recognize and distinguish the differences within the Operating Systems itself. This goes back to my initial theory, that FSX, might be having problems recognizing uiautomationcore.dll in some way, as the one which was being used on my box was version 7, from the 64bit \SysWOW64 directory.

Hence, I have since changed that to be the 32bit version 7, from the \System32 directory. It is not the .Net Framework 2x equivalent, but it does move the .Net Framework version down two (2) versions and gets it closer to the 2x code. The hope is that there is enough stability in that version to keep FSX happy. The Vista version of uiautomationcore.dll might also be a way to push back closer to .Net Framework 2x.

I guess this is all predicated on another one of Steve Ballmer's "excellent" bright ideas.

The bottom line is that given the component interoperability path that Microsoft took, when it decided to move in the direction of .Net Frameworks several years ago, without continual base code management and maintenance, FSX is essentially a dying application. The further way .Net moves, the more faint FSX becomes in the interoperability rear view mirror. At some point, with the continual changes in Windows and its perpetual shifting of its .Net internals, FSX will become so unstable as to be rendered completely useless, as you won't even be able to launch it inside Windows in the years to come. As .Net gets continually updated and as Microsoft moves closer to "optimizing" Windows 8, expect to see more component level interoperability issues come up with respect to FSX and its handling of dynamic link library files.

You are witnessing the death of a Legend. Pure and simple. Hold on for as long as you can - that's pretty much the only hope at this point. This patient is on life support, but the majority are not yet willing to pull the plug. I'll be happy, if I can get through my initial real flight training with FSX as my simulated procedures platform, as X-Plane simply does not have the required aircraft models that I need to get the job done.

When it comes to FSX, Plug'N Play has turned into Patch'N Go.

[aputech]

SmallJet, what you so thoroughly researched and outlined (thank you so much, you really went the (most appreciated) extra mile, Sir!) is precisely what I had related to some folks here and another MSFS website in much simpler terms: I suspected that the Windows Updates were causing the ever increasing number of FSX crashes. Unfortunately, probably because the presentation of my observations were so casually presented, my findings weren't taken very seriously. I arrived at my conclusion to the root cause FSX of uiauto crashes by simple observation: two of my PCs, both running FSX; one with Windows Updates, one without.
Thanks to you, my initial assumptions regarding the root causes of the uiautomationcore.dll have been, in large part validated, but I'm still working on the actual "smoking gun," so to speak.

Again, thank you so much for sharing your information.

aputech

[SmallJet]

SmallJet, what you so thoroughly researched and outlined (thank you so much, you really went the (most appreciated) extra mile, Sir!) is precisely what I had related to some folks here and another MSFS website in much simpler terms: I suspected that the Windows Updates were causing the ever increasing number of FSX crashes. Unfortunately, probably because the presentation of my observations were so casually presented, my findings weren't taken very seriously. I arrived at my conclusion to the root cause FSX of uiauto crashes by simple observation: two of my PCs, both running FSX; one with Windows Updates, one without.
Thanks to you, my initial assumptions regarding the root causes of the uiautomationcore.dll have been, in large part validated, but I'm still working on the actual "smoking gun," so to speak.

Again, thank you so much for sharing your information.

aputech

It is only a suspicion that I have, but it is a strong suspicion based on observation. I would actually need multiple configurations running Win5, Win6, Win7 and Win8, from .Net 2.0 through the new .Net beta 4.x, before I could fully (100%) convince myself that this is the case.

My internal suspicion about the base code of FSX, comes from having worked in Silicon Valley enterprise technology companies ranging from initial start-ups to a couple very well known household name type giants. ALL of them took the exact same attitude with respect to interoperability on the Windows platform. They all realized (at some point in their early existence) that Microsoft was in many ways, an unstable platform for building mission critical business applications. Internally, this is a terrifying reality for most true enterprise software companies out there trying their best to produce hard hitting (serious) business solutions for corporations and governments. But, I digress...

I think the deal is a .Net issue. I could be wrong - however, I've not had a singular uiautomationcore dump since moving the Win7 32bit version into the root of FSX. Coincidence? Maybe. But, thus far, my suspicions are oddly confirmed.

On the issue of Windows Updates. I just ran one. I also just installed some Orbx/FTX as well. No AppCrashes to report. Of course, within the WU, I'm looking for instances of .Net upgrades/patches/bug fixes. I doubt seriously that Microsoft will be changing (drastically) how the automation Clients and Servers work, but I also believe those might be contributing factors for the AppCrash at run-time.

Lastly, in general terms, some of the future requirements of third-party add-ons may unwittingly contribute to the slow death of FSX as well. I'll give you just one example that I recently encountered. I just installed additional add-ons yesterday that required .Net 3.5. Well, FSX does not "require" .Net 3.5 as that level of the Framework did not even exist when the FSX base code was hardened for initial RTM. Yes, FSX did undergo some significant changes to its overlaying source code with Aces, but much of the underlying base code remained intact and did not cater to the future needs of third-party developers who might seek out the .Net Framework as the base platform for component integration in their own products.

This fact is probably creating some collisions between what FSX requires and what third-party add-ons require now, and what they will require in the future. FSX and most importantly, third-party development, is in a state of stasis right now. If third-party developers locate the sweet spot between the older version(s) of .Net that FSX is comfortable with, and balance that need against their need to use the latest improvements in the current and future versions of .Net that FSX is not designed to use, then you will have a third-party vendor producing products that appear (on the surface) to be more cooperative with FSX, when in reality they might not be taking advantage of future .Net gains.

This whole thing is pretty stupid when you stop to think about it, IMO. Before I got involved in flight sims about five (5) weeks ago, I had no idea that the genre had such a huge following in the public. You've got people in Japan, using FSX, for goodness sakes. People in India, enjoy the flight simulator as well. People in Napal, of all places and even in China, save my breath, are using the darn thing. That's called a Scaled Market and that is NOT something that any wise software company should ever just walk away from and abandon like Ballmer, at Microsoft.

The other thing I don't yet understand (but that I am looking for answers to), is why on earth Aces, didn't go out and secure venture capital to put the company on good financial footing, when Microsoft walked away. Sure, Microsoft, most likely told Aces that it could not use the source code, but who cares - they had the knowledge about how to build a flight simulator that worked. They could have built their own. Yes, it would have taken a round of VC, or may be strong Angel willing to sit down and listen to the market potential storyline being told by the leaders of Aces - but it could have been done.

Now look at what are they doing - Scuba Diving simulations off the cost of Aruba? I mean, come on. I like Scuba Diving just as much as the next guy. I have no problem with swimming with the Sharks and virtually touching a Stingray, or hanging out with Tropic Fish that I can't see anywhere else in the entire world, but seriously - Diving! There are far more people out there who are interested in Flying, and there was a much bigger already existing install base to serve with a flight simulator that actually had a real future. There are some things in life I just don't understand.

After getting involved with the genre and seeing how passionate some people are, I'm "thinking about" the possibility of developing a new kind of Flight Simulation experience for the Desktop PC. I've got about 8-9 more months before my real flight training begins, so that gives me ample time to really think about what needs to be brought to the Flight Simulation World, that would set the global community of Flight Simmers on fire - literally.

I have some ideas that IMO, would transform things a bit:

1) Access to TrueModel Aircraft of a wide range of different Type and Category, including Military.
2) Built-in Photo Realistic 3D HyperGraphics Topology for the entire planet with Longitudinal/Latitudinal accuracy.
3) Real-Time Streaming HyperGraphics Flight Simulation via high-speed internet connection.
4) Built-in Photo Realistic 3D HyperGraphics Airports for the entire planet with full services (FBO, Gates, Fuel Service, etc.)
5) Real-Time simulated Flight Dynamics at the HyperGraphics Server level.
6) Real-Time simulated 3D HyperGraphics Atmospherics (Clouds, Sky, Winds, Rain, Snow, Fog, Wind Shear, Ice, etc.).
7) On-Time Global METAR Conditions (GMC) directly into the 3D HyperGraphics Atmospherics Server.
8) User configurable plain language Regional METAR Conditions (RMC) on the 3D HyperGraphics Atmospheric Server.
9) Real-Time live ATC with global coverage 12 hours per day: Sector/Regional/Area/Approach/Departure/Tower/Ground.
10) High Fidelity simulated ATC coverage in low density airspace 24 hours per day and through non-live coverage hours.
11) Real-Time Streaming HyperG WebClient designed expressly for HyperGraphics Flight Simulation delivery to the desktop.
12) TrueModel of Garimin's GNS430/GNS530/G1000/G3000, Rockwell Collin's Proline Fusion and Avidyne FlightMax Integra.
13) TrueModel fully functional HyperGraphics 3D Cockpits, Flight Decks and Cabins.
14) Built-in multi-player facility complete with VenueWorld Technology for things like staging and arranging Multi-Player Airshows.
15) Real-Time live access to every major Aviation and Aerospace Museum in the world, through a new Learning & History Center.
16) Real-Time live access (and pre-recorded video) to Virtual Flight Instruction Classes & Programs, through a new Virtual Flight Academy.
17) Flexible & Secure online (on-demand) low cost payment options.


This would provide for:

a) No more installation of a fat client flight simulator software to the hard-drive.
b) No more need to install and maintain multiple software programs as "add-ons" and "plug-ins".
c) No more need to separately maintain and mange your aircraft model database.
d) No more need to install and maintain separate Weather, Texture, Topology, Airports, Lighting, Mesh, LandClass, etc.
e) No more need for flight simulator optimization tweaks for higher FPS.
f) No more frustration over being forced to sacrifice performance for higher frame rates.
g) No more component interoperability conflicts.
h) No more frustration with half-baked and partial functioning Avionics. "TrueModel Technology" solves that problem.
i) No more guessing. An initial gateway opportunity to an Aviation and Aerospace Primer Education.

Giving it some superficial level thought at this point. Just tossing around some concepts and ideas in my mind and still learning about what's really necessary to truly replicate the operations and procedures associated with flying real aircraft. All the end-user would need to do is install the HyperG WebClient and go out and purchase their Flight Control System of choice. All mainstream hardware for flight controls would have built-in native support with the HyperG WebClient.

It is my belief that you should not have to be an enterprise technical support engineer, just to be able to fully enjoy your flight simulator experience - nor should you have the responsibility of constantly being plagued with the hassles of upgrading and maintaining it.

Just some free floating thoughts at this point. If I get motivated enough, I'll take to the next level which would including sitting down with developers privately and throwing around ideas about possible design architectures with the current state of technology available. If it gets more serious, then I'll look at what funding such a ramp up endeavor might entail. Either way, whether I decide to do it or not, I do believe that a new level of what I'm calling a "TrueModel" Flight Simulator Experience is long overdue. It should be a platform capable of serving the needs of everyone involved:

- Those working on their real world Pilot Ratings (Glider, Private, Jet Type, Rotor)
- Real world Pilots working on their Currency (skills, memory work and procedures)
- CFIs and CFIIs looking for a Training Bridge for their students to fill the gap between Theory & Application
- Hardcore Flight Simmers who will never obtain a real world Pilots License, but who want the highest in Graphics Fidelity.
- Casual Gamers just out looking for some Saturday afternoon fun without any career orientation towards aviation.

This spans a huge market with multiple segments, each having a completely different reason for wanting to use a Flight Simulator and I believe they all deserve a TrueModel Technology experience.

I'll need a new name for the flight simulator. I think I'd might call the finished product: Velocity. The working project code name might be something like: Sedona.

Hmmmm. This is starting to feel like more than just "superficial" idea tossing. Maybe this is how stuff like this gets started. Somebody gets frustrated with the current state of affairs and decide to make a better widget. A TrueModel widget, no doubt. Project Sedona. That seems just about right. Who knows at this point.

[SmallJet]

Rockwell Collins Proline Fusion EFIS:

[loki]

The other thing I don't yet understand (but that I am looking for answers to), is why on earth Aces, didn't go out and secure venture capital to put the company on good financial footing, when Microsoft walked away. Sure, Microsoft, most likely told Aces that it could not use the source code, but who cares - they had the knowledge about how to build a flight simulator that worked. They could have built their own. Yes, it would have taken a round of VC, or may be strong Angel willing to sit down and listen to the market potential storyline being told by the leaders of Aces - but it could have been done.

Now look at what are they doing - Scuba Diving simulations off the cost of Aruba? I mean, come on. I like Scuba Diving just as much as the next guy. I have no problem with swimming with the Sharks and virtually touching a Stingray, or hanging out with Tropic Fish that I can't see anywhere else in the entire world, but seriously - Diving! There are far more people out there who are interested in Flying, and there was a much bigger already existing install base to serve with a flight simulator that actually had a real future. There are some things in life I just don't understand.

Microsoft owned Aces, and didn't give any warning when they closed it down. I don't think they could have just raised money somehow and separated (unlike Bungie). And not all of the former Aces developers went to Cascade Game Foundry. At least a few are now working on Prepar3D at Lockheed Martin.

3) Real-Time Streaming HyperGraphics Flight Simulation via high-speed internet connection.

What about all of the people who don't have a suitable high speed connection (reliability, data caps etc.)? Or those that like to run the sim on laptop so they can fly while away from home?

[mgh]

The other thing I don't yet understand (but that I am looking for answers to), is why on earth Aces, didn't go out and secure venture capital to put the company on good financial footing, when Microsoft walked away. Sure, Microsoft, most likely told Aces that it could not use the source code, but who cares - they had the knowledge about how to build a flight simulator that worked. They could have built their own. Yes, it would have taken a round of VC, or may be strong Angel willing to sit down and listen to the market potential storyline being told by the leaders of Aces - but it could have been done.

Could it?

Perhaps potential funders felt the idea wasn't commercially viable and wiouldn't fund it.