在所有appdomain中加载的混合模式程序集

Question

Our application sets up a AppDomain that we load some modules into. One of these modules is using a legacy mixed mode DLL for interacting with H5-files. The problem is that as soon as the mixed mode DLL is loaded a handle is placed both in the new AppDomain but also in the original AppDomain that was created when the application started.

The handle in the new AppDomain naturally goes away when we unload that AppDomain but the handle in the original AppDomain remains and is pinned. This leads to fragmentation of our managed heap.

I can't locate anything in the mixed mode source code that would explain this behavior. The only thing which looks suspicious is the following call that uses a native static string:

H5Utils::throwError( String^ message ) {
  String^ stackStr = gcnew String( H5Utils::errorStack_.c_str() );
  String^ myMessage = message + "\n\nError stack: " + stackStr;
  throw gcnew H5IOError( myMessage );
}

where H5Utils::errorStack_.c_str() is the native static string. But this method never gets called and the module gets loaded into both AppDomains immediately when the mixed mode DLL is loaded.

Does anyone know why a handle would be created in both AppDomains?

Answer 1

So I dug into this some more and have found an answer so I thought I answer my own question if someone runs into the same problem.

The reason the module is loaded into both AppDomains is due to the usage of native global values and static member values. This actually makes sense since these values are allocated on the native heap and if this module is used in more than one AppDomain there is a high probability that you still want to share these values.

The problem is when you are constantly creating and destroying AppDomains and load these kinds of resources since the references that get added to the running process first AppDomain are static and hence causes pinning. This makes the managed heap fragmented and long running process will start eating up memory.

To solve this Microsoft added __declspec(appdomain) which should be added to globals of native types which makes them reside only in the AppDomain where the module was created. Turning on /clr:pure will make this the declaration as well. Most of this is described in msdn's help on appdomain

A final gotcha is that you must be aware of your #include files. For instance #include <string> will cause the module to be shared between AppDomains while #include <stdio.h> will not.