Was this for our own good? (Part III) - a.k.a. "Fault Tolerant Heap??? I don't want your Fault Tolerant Heap..."

I've been doing some work on the AIRAC database loader for our upcoming FSLabs A320 addon... mainly to make it load faster. Well, that's an excuse - the real reason was, I read an article about the new Concurrency features that Visual Studio 2010 provides and I was really curious if using the Concurrency library would make things faster by parallelizing some specific pieces of my code - and guess what! It does!

The example code I chose was the AIRAC database file that contains the NAV FIX points - all 183 thousand of them, which were previously being loaded serially through the file - I thought, wouldn't that be a good example for parallelism?

I changed the code to allow for Concurrency - and had a simple heap corruption error... that I couldn't find at first (don't worry, I've found it since). Three test runs later, the debug version of my test application started running VERY slowly... and I mean VERY slowly... (about 100 times slower per 5000 fixes read in), making things quite undebuggable... ("but I hadn't changed anything, I swear!") and that was one of those moments when I started staring at the screen, not quite knowing "WTF" (I saw somewhere an explanation of this from a father to his child... Sir, it does NOT mean "Welcome To Facebook" - but I digress...)

Then an epiphany occurred. One of those light bulb moments, when you look at the debugger output window and notice an extra line there that wasn't there before...

 "Fault tolerant heap shim applied to current process. This is usually due to previous crashes."

A bit of Googl Microsoft Bing-ing later, and I could find the reason: Windows 7, in all its Microsoft spirit ("Don't worry, we'll fix it for ya!"), decided that my heap was getting corrupted too often by this irresponsible and stupid application executable and needed some more totalitarian help... ("Sir, nothing to see here, move along"), so it added the (debug) executable to its internal list of "applications which don't behave".

Long story short, when FTH (Fault Tolerant Heap) services are active for a specific application, it starts CRAWLING instead of running properly because each heap activity (which, for 183 thousand entries means 183 thousand of them) would be monitored and followed...

The solution was simple enough: Kill the specific FTH registry entry for that app, restart - all is well again.

The registry key where all this 'magic' exists is

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\FTH\State

if you find ANYTHING in there, other than the (Default) key, please be aware that that specific app will behave very poorly, because "Big Brother" is watching it.

Wouldn't the solution be simpler if instead of making our apps silently crawl, Microsoft would simply pop a message up saying "Your app sucks. Fix it, or else"?

FlightProSim (or ProFlightSim or ProFlightSimulator) - a scam?

For days now, I've been subjected to unwanted advertisement when I log onto my Facebook account, by a newly formed (?) company out of Australia claiming to have developed "The Most Realistic Flight Simulator Ever Created For Desktop Computers".

Now, I've kept in touch with almost all the PC flight simulator development teams globally for the past ten years or so and it came as somewhat of a surprise to see an unknown entity suddenly appear with such bold claims - I admit, it felt quite embarrassing to me.

It didn't take long, however, to understand what sort of "deal" these people are offering - misleading at best, outright shameful and quite annoying for the majority of simmer friends globally who have contacted me to ask if I have any "inside scoop" on this "new simulator", only to discover the truth at the end.

You see, this is nothing else but a quiet rebranding of the GPL'ed (thus forever free) and well-known Flight Gear simulator that has been in development for many years now by a team of volunteers who do not charge (or receive) a single penny for their efforts.

Read the entire scoop here.

To you, Mr "Dan Freeman- 13 Hickson Road, Walsh Bay, Sydney, NSW, Australia" (that's the owner of that "ProFlightSim" web site at the time of this blog post writing), all I have to say is: Shame, Shame, Shame!

When to gripe to your Virtual Private Server ISP...

As some of you might know, apart from running Flight Sim Labs, Ltd., I have also been wearing the co-administrator hat for FSDeveloper.com for a couple years now...

Not so long ago, the FSDeveloper admins (Arno, Nick, Jon and myself) selected to move FSDeveloper.com to a new server ISP facility, as demand had grown substantially over the years and the older one was showing signs of old age. For reasons of familiarity, we decided the new server would be a Windows-based solution, running on a Virtual Private Server (so costs could remain very low, as we have no real income to support this volunteer-based effort).

This worked exceptionally well since the switch, allowing us to provide better service to our "customers" (Flight Simulator developers) with some nice new facilities, etc.

However, for the past couple months now, we've been getting reports by our users complaining that the server was not too stable - some times they'd be able to log on, other times they'd get connection timeouts or "reset by host" errors. While this was happening, our Domain Name Server also had some issues, so we attributed the problems to faulty name to IP resolutions.

Well- today the problem returned - and returned to stay. Nobody could connect to the web site or the forums, no matter what their location was, their browser, or their ISP. At the same time, however, the administrators could log on to the server via Remote Desktop, so it didn't look to be a network connectivity issue...

Digging into our server showed that while IIS 6.0 was running perfectly well, there were absolutely no user connections honored - instead, a bunch of "Connection_Refused" errors would appear every minute or so in the HTTPERR logs.

Some aggressive googling later, we identified the culprit:

Our ISP has selected Virtuozzo for their Virtual Private Server hosting solutions and our FSDeveloper.com server is one of many VEs running on the same 32-bit physical machine.

While total free RAM on the physical machine is not as important, the case is not so with memory that cannot be "paged out" to disk (such as memory used by critical processes and drivers that need to stay in place all the time). 

The problem was isolated to IIS6.0 and non-paged memory pool shortage issues. IIS will refuse any new connections if it detects that non-paged memory pool usage has increased enough to leave less than 20Mb available on the physical machine (hence the many "Connection_Refused" errors in the HTTPERR logs).

We verified this was the problem by using a workaround - adding a "EnableAggressiveMemoryUsage" registry entry which temporarily fixed the problem, signaling that IIS should not refuse connections until free memory falls below 8MB of non-paged memory pool.

While we're elated that we can now serve our loyal FSDeveloper followers once again, we are a bit frustrated that the REAL solution will have to come from the ISP:

a) limit the number of VEs on the same machine so non-paged memory pool usage is reduced,

or

b) move our virtual server instance to a different machine with less VEs

Solution c) is also a possibility: Selecting a dedicated server to host FSDeveloper.com - however, the expense for this would be about five times larger than the existing solution, so it cannot happen at this time...

Let's see what our friendly ISP has to say about this problem. I'll keep everyone posted when I hear back!

FSX Performance tip

I see this question asked over and over again in forums: "What can I do to increase my FSX performance"? More often than not, the question is answered in ways that I'd describe as... entertaining, but far from true.


Here's a small tip that will fix your FSX performance, almost doubling your FPS, if you are unlucky enough not to have been aware of the consequences:

If you run FSX in Windowed Mode and have the FSX window maximized, sometimes the Windows Start button will overlap your FSX window. If your machine is powerful enough, you'll tend to be annoyed by the seemingly low FPS, but performance will be enough for you to simply be puzzled.


Resize the FSX window to allow the Start button NOT to overlap (or simply hide the taskbar) and you'll find that performance will increase - sometimes even double.


Same holds true for ANY external window that overlaps the FSX display - don't let any of those small popups come in view, as your FPS will drop to almost half (the technical reasons are outside the scope of my note here).


Let me know if you had this issue and if my advice above fixed it!

More info about Microsoft Flight

Microsoft posted some more information on Flight, together with another teaser video.

Find it here.

Microsoft Flight

The cat is out of the bag, it seems... (well - sort of).

Watch the announcement video here and then talk about it here...

Reawarded!

Seems that Microsoft thought that I did good last year again, so they reawarded me as MVP.

My sincere thanks goes to Alessandro and the other people responsible for this (you know who you are!) - I hope I can keep doing what I've been doing to deserve this!

PLEASE don't do this...

I am going to address this blog entry to my fellow Flight Simulation Addon product developers. Some are more experienced than others, we all have a common goal, though: To produce quality addons which will make our simulation audience happy.

Fellow developers, PLEASE don't alter other people's (or companies') registry entries or paths. I know you think you're doing the world a service, but in fact, you're causing (inadvertently, I know it) severe support pains and aren't even aware of it.

Altering a registry key value, ESPECIALLY one that is meant to be controlled BY THE USER, goes against all programming principles we've all learned while programming under Windows. And when that registry key happens to be the setup path where Flight Simulator is installed, you're adding pain and suffering above and beyond your intended goal.

So... please... for the sake of sanity (because where I've been, I am sure you will one time have to be as well). Don't do it. (or, at the very least, alert the user that you will be doing it... or... don't do it. Don't. Don't. Hope I was clear).

Makes me feel all warm and fuzzy inside...

I don't generally reproduce other people's material as a way to attract readers to my blog, however I have to make an exception here to re-post a note from our Flight Sim Labs forums, as I feel it most accurately represents why I gave up working at Wall Street to start my own flight simulation addon development software house...

I know Dan won't mind me pointing to his very eloquently put comments here.

Thank you Dan, for expressing EXACTLY why we at the "Labs" keep doing what we're doing...

Can you set DEP to "AlwaysOff" on your Dell laptop?

It seems that many people cannot - and unfortunately, this post does not talk about a solution, but rather as a heads-up, or a possible point of focus, for people who might have a solution to offer.

But what is the problem?

Well, as far as I understand it (disclaimer: I do *not* own a Dell laptop), Dell laptops come with a version of preinstalled Windows Vista or Windows 7 on them which has some funky partition mapping on the drive, as well as some disabled features.

For various reasons, there comes a time when users will want to turn the Data Execution Prevention feature off, by opening a Command Prompt Window and entering "bcdedit /set nx AlwaysOff". (This helps run applications that were developed before Vista was available which otherwise trip the DEP flags and crash on the user - some of them being Microsoft's own Flight Simulator series, FS2004 and FSX).

The command can be successfully executed (with administrator rights or elevated privileges), but when the user reboots (sometimes MUCH later on), they are faced with an error 0x7b and a Blue Screen of death (BSOD).

So far, the ONLY reports we have are coming from users with Dell laptops who have NOT scrapped the Dell-provided Windows installations.


The obvious workaround is for these users to FORMAT their drives and install a clean NEW version of Windows (preferably, Windows 7 x64 now), that does NOT come from the Dell-provided disks.


All attempts at contacting Dell about this problem have been met with no success for the moment.

So... do YOU have a solution for this problem? If so, and you are STILL running your Dell laptop with the original, Dell-installed Windows and you were able to turn DEP AlwaysOff, I'm prepared to offer you a free Concorde-X license as a thank-you for sharing that information with me :).

How to cleanly install your NVidia drivers

I get this question time and again. I usually suggest DriverCleaner, a utility that's very helpful in ensuring that there are no annoying remains of possible old drivers left in your system. However, I'll admit that's only half the story. For the best experience and the fullest solution, I recommend reading this article, which describes step-by-step what you need to do to get rid of all issues, once and for all (well, until you have to redo it, I guess).

Note: The article was written with Vista in mind, but it certainly applies to Windows 7 in the same way.

The 'disappearing textures' fix for FSX

A lot of bandwidth has been spent already by FSX users on a problem they are experiencing with complex add-ons, such as the Concorde-X, the LDS 767 and other similar products, whereby aircraft and scenery textures disappear after awhile, leaving them transparent, or worse, crashing the system, requiring a restart. This gets very frustrating, especially if it happens at the end of a long flight, right before landing your simulated aircraft.

Thanks to the dedication and hard work of a distinguished member of the FSX Community, Jesus Altuve, who I want to publicly acknowledge and thank via my blog, it seems that a fix for this problem (which has existed for the past four years, since FSX has been released) is now possible. Jesus has found some new fsx.cfg settings that are undocumented, but help alleviate this issue for everyone that has tried them so far.

It was, however, noted that not every member of our community is equally versed in making changes in their computer, especially when these changes involve digging deep into the internals of Windows folders, some of which are even hidden, and applying edits to files that are normally best left alone by the ordinary FSX user.

As such, I took some time to develop and provide an automated utility that will take care of the edits for you, allowing different levels of control to the various items that are there for editing.

Version 1.0 of the automated FSX Texture Fix utilty is already released in the FSLabs web site forum downloads section. I'd welcome some feedback if you use this utility, as the news on how these edits work is constantly coming and more discoveries are coming out as time passes.

Once more - please allow me to express our gratitude and thanks to Jesus Altuve for his dedication and hard work!

Without further ado, you can download the utility here.

So it's out...

The Concorde-X has been out for quite a couple weeks now and the responses have been overwhelming! So far, apart from a few small issues that all new product releases carry, our customers have been cheering this release, saying that it's one of the best products out there for Flight Simulator X!

I was browsing the net today and stumbled upon a wonderful podcast (and a video too!) from our good friends at FSBreak.net, which describes in detail what they think of our product!

Thanks guys, it means a lot to us that you feel this way!

Flight Sim Labs previews new Concorde-X in an amazing video!

Those of you who might not have caught this news so far, please take a look: