These both come from third party developers – one I was aware of and one was completely new to me.

The Debug Heap Is Slow

Veteran Windows C++ developers know this, but if you don’t spend a lot of time with MSVC, this might be new.

The default configuration of MSVC is to force use of the debug heap when the debugger is attached; this applies even to release builds of binaries that aren’t yours.

What this means is: if you do nothing else but start your plugin “inside” X-Plane, X-Plane will use Microsoft’s debug heap.

We avoid doing this internally because it is really, really, really slow. The debug heap provides some great tracking for finding memory problems, but the cost is really, really slow load time.

The fix is simple: add _NO_DEBUG_HEAP=1 to the environment variables for your debugger. You can do this in the control panel as shown in the linked article, or you can add it to MSVC’s debugger properties.

Other Things To Go Fast

As a side tangent, when debugging a plugin, find ways to load X-Plane faster. A few things that can help:

  • Turn off AI aircraft.
  • Pick a simple aircraft to fly (e.g. not the 747).
  • Go somewhere without scenery (or without much scenery, e.g. PMDY).
  • If you have to have scenery, turn 3-d all the way off.

My Plugin Won’t Reload

We receive periodic bug reports that plugins won’t reload on Windows. This is miserable for you as a third party developer – it means rebooting the sim instead of just reloading your plugin. But why does it happen?

I thought we had a bug, but a third party developer found this:

I did searched the registry for the names I’ve used for X-Plane 11 folder and found this items at
HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windws NT\CurrentVersion\AppCompatFlags\Layers

Each name used was included there with “$IgnoreFreeLibrary<win.xpl>”
value, after removing them and restarting X-Plane I got able to compile the plugin using the names again.

I have not found any official Microsoft documentation on this, just a lot of ranting from really annoyed programmers who want to know why the hell Microsoft would do this. If anyone has better Google-Fu than me and can find official docs, please do share. So what follows is my wild speculation of what’s going on.

In some old version of Windows, FreeLibrary probably didn’t actually (or immediately) free a DLL under certain circumstances. Application developers then wrote buggy apps that relied on this behavior, e.g. they freed a library while it was in use and their app didn’t crash.

Microsoft updated Windows and made FreeLibrary do what it says on the label, always, and old buggy apps started crashing left and right.

Microsoft, being Microsoft, did not say “you app developers are idiots, why don’t you go rewrite your buggy apps”. Instead, they added a feature to the App Compatibility Wizard that watches your app and, if it crashes after a DLL was unloaded and the moon is the right shade of Rondele, it adds a registry key marking this library as “never to be unloaded, even if this app says so”.

From that point on, the app doesn’t crash because the old semantics of FreeLibrary (“ha ha ha, you don’t mean that do you”) are restored in that one case.

The above is entirely made up – it’s my mental model for what might have happened, unless Raymond Chen someday gives us some back story.

Still, you can see what has gone wrong here – Windows decided that for compatibility reasons, plugins should not actually be unloaded, and since all of your DLLs are named win.xpl, this one plugin crash has caused plugins to never be unloaded. Thus the plugin unload/reload never releases the DLL and you can’t swap in new code.

Nuke the registry key and you’re back in business, at least until you crash again.

 

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

9 comments on “Two “Gotchas” Developing Plugins

  1. Thanks for this developer-centric post, Ben. Been testing at PMDY for years. The locals know me well, but wonder how I can afford so many different aircraft. Definitely want to give that environment variable a try, and Windows 7 was apparently never “fixed” as far as the app compatibility wizard is concerned. 😉

    For those testing plugins not needing anything outside the cockpit, they can help their ACF load times overall by temporarily removing complex 3D elements from the aircraft’s Misc Objects for highly detailed aircraft, and their frame rates by using Sandy Barbour’s drawing disabler. //www.xpluginsdk.org/misc_plugins.htm

  2. My ttechnique for faster development of plugins was to recompile the SDK as a set of stubs that did nothing but return a void or zero to be compatible with the SDK’s function declaration. This allowed the plugin to run without X-Plane and be tested within the Visual Studio debugger. Obviously there are things that you need the real X-Plane for, but I was able to do much of the testing this way and save a whole load of time.

    1. That’s a good idea – certainly for plugins beyond a certain size, developing outside X-Plane is a huge in…Sandy and I did that for the SDK 1.0 itself.

  3. My plugin disables the plane path. A side effect of this is that X-Plane does not update the groundspeed dr – fair enough – but neither does it let me write the groundspeed to it. This means that the Virtual Airline fraternity cannot get hold of this and other variables for ATC using XSquawkbox and similar.

    Is there any chance Ben, that this restriction could be lifted for the relevant variables? A lot of people ask me for this and I can’t see a way to implement it without modifying XSquawkbox etc.

    1. Please file a bug and include all ‘stuck’ datarefs. We do want to fix some of this, but it’s a surprisingly long-tailed problem, since the instrument indication simulation system wasn’t really meant for this.

      1. Much appreciated – I can understand your problems with this. I will do some research with the ATC guys and put together a list of what is needed.

Comments are closed.