Failed to unload app domain.

[yuvnith]

We have a WiX installer which was developed using WiX 3, now we are upgrading it to use WiX 4.
We are seeing an exception which says "Failed to unload app domain", when we quit/complete the installation after calling Engine.Quit(), and the setup is not closed immediately,

Complete Error:

[C6F0:F4C4][2023-12-26T16:38:54]i500: Shutting down, exit code: 0x0
[C6F0:F4C4][2023-12-26T16:39:06]e000: Error 0x80131015: Failed to unload app domain.

I have looked into some BA examples from WiX v4 github repos and observed that a window handler is passed within Detect Calls and the same window is disposed during exit. Is it relevant to the above issue which I am facing ?

private void ShutdownUiThread()
        {
            if (this.dummyWindow != null)
            {
                this.dummyWindow.Invoke(new Action(Application.ExitThread));
                this.dummyWindow.Dispose();
            }

            var exitCode = this.result;
            if ((exitCode & 0xFFFF0000) == unchecked(0x80070000))
            {
                exitCode &= 0xFFFF; // return plain old Win32 error, not HRESULT.
            }

            this.Engine.Quit(exitCode);
        }

Can any one please share some insights or the documentation link which explains this behavioral difference between WiX v3 and v4 during shutdown ?

[robmen]

This is the documentation for upgrading your custom BA from v3 to v4: https://wixtoolset.org/docs/fourthree/faqs/#converting-bundles

[yuvnith]

Further examination of the WiX source code found that mbahost.cpp -> BootstrapperApplicationDestroy() is where the issue is thrown. I am unable to identify the problem's root cause.
Following the Engine.Quit(), we run a Dispatcher.InvokeShutdown(). With WiX v3, this worked well, but not with WiX v4.

Would you kindly assist me in determining the root cause?

[DS-AndOrz]

I also see this error frequently in logs of bundles that use a custom BA that was migrated from v3 to v4.
I seems that this also sets a reboot needed flag but no package apply required a reboot.
The https://wixtoolset.org/docs/fourthree/faqs/#converting-bundles docs don't mention something special in this area.

The calls to Engine.Quit() happen after the Dispatcher.InvokeShutdown() in the custom BA.
So I guess that it is something in the engine itself or in the engine <-> custom BA communication.
I can't see that this error blocks or hinders the close itself in the logs.

In the develop branch the mbahost.cpp is gone, so my next guess is that v5 works differently in this area and the issue will be gone.
Am I right?

[robmen]

Your BA may be exiting too fast to receive the shutdown callback. But you are correct; the model in v5 is quite a bit different (see #7916).

[MichaelCross5129]

Was migrating to v5 able to solve this issue?
I'm having similar seeming issues of Engine/BA communication where the Engine.Quit(0) happens after the Dispatcher.InvokeShutdown() and the BA processes never terminate.

[yuvnith]

Yesterday, I was able to get around this by using the dispatcher from the Run() method rather than the ManagedBootstrapper constructor.

Old

        public ManagedBootstrapper(IEngine engine, IBootstrapperCommand command) : base(engine)
        { 
            //global variable
            ApplicationServices.BootstrapperDispatcher = Dispatcher.CurrentDispatcher;
        }

New

protected override void Run()
        {
           ApplicationServices.BootstrapperDispatcher = Dispatcher.CurrentDispatcher;
        }

This example follows the same approach.

The dispatcher from the constructor has an MTA apartment state, whereas the dispatcher from the run() has a STA apartment state. More analysis of this situation is required.

[MichaelCross5129]

Unfortunately, this was not my issue and I am already using the STA state dispatcher from Run().

Thanks for taking the time to revisit and respond though!

[robmen]

We leave conversations open so they are found by search. Closed conversations tend to "disappear".