AppDomainUnloadedException (OLE error 80131015)

Hello,

We are using several .net (c# with WPF) modules in a Delphi 7 application with the help of Hydra 4.0.71.1093.

We are loading modules by using the following code :

FHYModuleManager := THYModuleManager.Create(nil);
FHYModuleManager.ResolveInterfacesToOwner := False;
FHYModuleManager.CustomImplementer := Self;
FHYModuleManager.OnBeforeUnloadModule := OnBeforeUnloadModule;
FLog.LogMsgParam(’**** Loading HYDRA dll for %s %s ****’, [FName, FHydraPluginPath], logInfo);
HYModuleManager.LoadModule(FHydraPluginPath, True);

We want all modules to load into a new separated AppDomain.

When our delphi app is being closed by user, we destroy Hydra modules by using following code :

try
FHYModuleManager.CustomImplementer := nil;
FHYModuleManager.UnloadModule(FHydraPluginPath);
FHYModuleManager:= nil;
except
on E: Exception do
begin
FLog.LogMsgParam(‘Failed to free Hydra module : %s’, [E.Message], logError);
end;
end;

When this code is executed on our developer machines, AppDomain unloads correctly without any AppDomain Unload errors.

Some of our clients (that are using our software from the morning to the evening, everyday) sometimes have an exception when unloading Hydra modules (Failed to free Hydra module : OLE error 80131015) which is a .net AppDomainUnloadedException.

We are not able to reproduce this issue on our dev machines, but some of our clients have the problem after a few hours of use (not all the time, seems to be random)

Is it possible to get an access of the AppDomainUnloadedException exception (stacktrace) to be able to have the exception details and to have the exception telling us why the unload domain failed ???

Thanks for your help, we are getting crazy since 2 weeks with this problem !

Frederic

As MSDN states

And the debugging advice is

https://social.msdn.microsoft.com/Forums/vstudio/en-US/01feeacf-883b-4058-b6c4-40ddbd67fa79/error-while-unloading-appdomain-exception-from-hresult-0x80131015?forum=clr

Actually this could be the cause: http://ntcoder.com/bab/2014/09/17/cannotunloadappdomainexception-on-appdomain-unload-that-has-displayed-a-wpf-windowdialog/

Hello Anton,

we are having the same problem, using Hydra 4.4.67 (host in Delphi XE7, visual plugin in C# with WPF). On some clients, the messages “OLE error 80131015” appears, when the module is unloaded.

We can even reproduce it on our development environment (Visual Studio): there we get an exception “System.AppDomainUnloadedException was unhandled. Message: Attempted to access an unloaded AppDomain” at some point AFTER the AppDomain.CurrentDomain.DomainUnload is triggered. Unfortunately no call stack or any other additional debug information is supplied.

The error is avoided when the module is loaded in the same app domain (i.e. by calling LoadManagedModule() with the second parameter set to “false”). But this solution doesn’t work for us, because we need to open several instances of the same plugin simultaneously.

I would really appreciate any hints, because we have been tied up with this problem for quite some time now.

Thank you!

Helmut

Hello

Could you attach Visual Studio to the app and tell it to pause execution when the System.AppDomainUnloadedException exception is triggered? Also could you make sure that all threads (if you use any) spawned by the plugin are finished in time? This could theoretically be the issue when the unmanaged call (like some socket operation) is not terminated in time while the domain is unloaded.

Hello,

Thank you for your ideas.

Visual Studio actually pauses execution when the exception is thrown, but gives neither stack trace nor any other exception details.

However, the thread window lists a bunch of threads which are active when the exception occurs:

Not Flagged > 11776 1 Main Thread DispatcherThread Normal
Not Flagged 9956 2 Worker Thread Highest
Not Flagged 12532 5 Worker Thread Normal
Not Flagged 14720 8 Worker Thread Normal
Not Flagged 9436 9 Worker Thread Normal
Not Flagged 12168 10 Worker Thread Normal
Not Flagged 13920 11 Worker Thread Normal
Not Flagged 11132 14 Worker Thread Normal
Not Flagged 13236 15 Worker Thread Normal
Not Flagged 1912 16 Worker Thread Normal
Not Flagged 15148 0 Worker Thread Normal

We are unable to track down the source of these threads. Do you think it might be possible that these threads are created in the course of Hydra calls from the host app, and not properly disposed of when the module is unloaded?

On the Delphi side, we also get an exception when the module is unloaded:

“system exception (code 0xc000041d) at 0x75f0dae8”

Here we also get a call stack, but it doesn’t seem to be of much use:

:75f0dae8 KERNELBASE.RaiseException + 0x48
:5e8da701 ; C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
:5ea842e7 ; C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
:5eb4b2aa ; C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
:190ae683
:73d884f3 USER32.SetManipulationInputTarget + 0x53
:73d66c40 ; C:\WINDOWS\SysWOW64\USER32.dll
:73d66820 ; C:\WINDOWS\SysWOW64\USER32.dll
:73d6d169 ; C:\WINDOWS\SysWOW64\USER32.dll
:77098e56 ntdll.KiUserCallbackDispatcher + 0x36
:505c2bf0 TControl.WndProc + $2C0
:505c76bf TWinControl.WndProc + $5D3
:5070ce75 TCustomForm.WndProc + $631
:0293446e TsuiForm.NewParentWndProc + $362
:505c282b TControl.Perform + $27
:505c6aa2 TWinControl.UpdateShowing + $112
:505c6bb1 TWinControl.UpdateControlState + $C1
:505c9833 TWinControl.CMVisibleChanged + $2B
:505c76bf TWinControl.WndProc + $5D3
:5070ce75 TCustomForm.WndProc + $631
:0293446e TsuiForm.NewParentWndProc + $362
:505c282b TControl.Perform + $27
:505c11c7 TControl.SetVisible + $2B
:5005f10b TObject.Free + $B
:763a38f4 KERNEL32.BaseThreadInitThunk + 0x24
:77085de3 ;
:77085dae ;

Any more ideas?

Thank you in advance,
Helmut

Hello

There can be a dozen of possible reasons, starting from stuck finalizer thread (I’ve seen that issue once - due to internal .NET exception the finalizer thread was stopped and add disposed objects were not removed from memory) up to a thread that is doing some uninteruptable operation and thus cannot be stopped. I just cannot diagnoze the issue w/o seeing it locally (and even then it won’t be easy).

f.e. you can add NLog to the plugin and log every start and every stop of spawned threads. Then once the error occurs you’ll be able to pinpoint the thread. Then replace the suspicious operation with its mock. If the error goes away - then you have found the cause. Then you’ll need to somehow rework that operation to make sure it finishes before the domain unloads (f.e. add som kind of Cleanup method and stop everything there)

Hope that helps

Hello,

Thank you, we are trying to pinpoint the threads which are active when the exception occurs.

But we made another interesting observation with a test host: The exception is NOT thrown at the moment the module is unloaded, but only afterwards, as soon as the host application loses focus. Does this help to isolate the cause of the error?

Another observation that may be significant: The OLE error appeared the first time after we had ported out project from Delphi 2007 to XE7.