CompositionTarget::GetCompositorForCurrentThread: don't originate an error during core shutdown

[Abhijeet Jha (iamAbhi-916)]

Description:
An app that enables DebugSettings.FailFastOnErrors and uses AcrylicBrush fail-fasts with 0xC000027B during normal shutdown. Dev Home hits this on every exit.

The stowed exception is hr=8001010E (RPC_E_WRONG_THREAD) originated at CompositionTarget.cpp:227, in the destructor of a brush that XAML is itself tearing down.

Root cause:
DXamlCore::DeinitializeInstance sets m_state = Deinitializing (DXamlCore.cpp:1026) and then runs CommonShutdown -> ShutdownAllPeers, which releases peers and destroys the brush.

SHUTDOWN - DXamlCore::DeinitializeInstance, m_state = Deinitializing

  DXamlCore::CommonShutdown                         dxaml/lib/DXamlCore.cpp:1052
  +- DXamlCore::ShutdownAllPeers                    dxaml/lib/DXamlCore.cpp:1873
       +- DependencyObject::EndShutdown -> DisconnectFrameworkPeer -> ClearPeerReferences
            +- AcrylicBrush::~AcrylicBrush          controls/dev/Materials/Acrylic/AcrylicBrush.cpp:26
                 +- MaterialHelper::NoiseChanged    controls/dev/Lights/MaterialHelper.cpp:265
                      +- LifetimeHandler::TryGetMaterialHelperInstance
                      |    controls/dev/Common/LifetimeHandler.cpp:106
                      |    auto ignorehr = ...GetCompositorForCurrentThread(...)   <- result ignored by design
                      |
                      +- CompositionTarget::GetCompositorForCurrentThread
                           dxaml/lib/CompositionTarget.cpp:227
                           IFC_RETURN(CheckActivationAllowed())                    <- returns RPC_E_WRONG_THREAD
                                                                                     and originates it

       IFC_RETURN -> error context stowed
         ShouldFailFastOnStowedException            components/base/errorcontext.cpp:1169
         g_failFastOnErrors set via DebugSettings   dxaml/lib/DebugSettings_Partial.cpp:72
         -> FAIL_FAST_USING_EXISTING_ERROR_CONTEXT, 0xC000027B

The HRESULT is correct and the caller already handles it. The defect is that an expected teardown condition is originated as a failure, and FailFastOnErrors cannot tell the two apart.

Fix:
Return the HRESULT without originating it when this thread's core is shutting down.

Behavior:
Callers on a live core are unaffected and still get a Compositor.

A query during core shutdown returns RPC_E_WRONG_THREAD to the caller exactly as before, and no longer originates an error context, so FailFastOnErrors does not fire.

A query from a thread that has no core still fails fast.

Testing:
Repro'd locally in a WinUI 3 app, merge base against the fix, one process per case, swapping only Microsoft.ui.xaml.dll (amd64chk).

Acrylic has to actually render for the bug to arm: MaterialHelper::m_acrylicCompositor is only set in AssertUniqueCompositorOrUpdate, which the solid-colour fallback path never reaches, so the repro forces the real acrylic path through MaterialHelperTestApi.IgnoreAreEffectsFast and exits with the brush still in the live tree.

case	merge base	fix
AcrylicBrush released by ShutdownAllPeers, FailFastOnErrors on	0xC000027B	0
same, FailFastOnErrors off	0	0
GetCompositorForCurrentThread on a thread with no core	0xC000027B	0xC000027B
GetCompositorForCurrentThread on the UI thread, live core	0 (Compositor)	0 (Compositor)
GetCompositorForCurrentThread after the core is deleted	0xC000027B	0xC000027B

Exactly one cell changes. Row 2 confirms the crash requires the FailFastOnErrors opt-in, rows 3 and 5 confirm the diagnostic is preserved outside the shutdown window.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[azure-pipelines]

Azure Pipelines:
There may be pipelines that require an authorized user to comment /azp run to run.

[Abhijeet Jha (iamAbhi-916)]

/azp run

[azure-pipelines]

Azure Pipelines:
1 pipeline(s) were filtered out due to trigger conditions.

[Godly T.Alias (godlytalias)]

Dropping IFC_RETURN will just avoid storing stowed exception which in turn may impact debugging as we won't be having a stowed exception captured in case of a real failure

[Godly T.Alias (godlytalias)]

Can't we avoid calling this if shutting down?