dotnet/wpf · error · InvalidOperationException

SR.OperationCannotBePerformed

Error message

SR.OperationCannotBePerformed

What it means

The MSAA Accessible wrapper (client-side provider proxies) converts an unhandled IAccessible COM failure into InvalidOperationException(SR.OperationCannotBePerformed, e). When HandleIAccessibleException decides the exception should propagate, or rethrows generically, callers see 'the operation cannot be performed' with the original COM exception as InnerException.

Solutions

  1. Inspect InnerException for the COM HRESULT to identify the actual failure and address it.
  2. Catch InvalidOperationException around Accessible property/method use and retry after the UI settles.
  3. Re-acquire the AutomationElement/Accessible reference — the underlying MSAA object is likely stale.
  4. If the app is yours, fix the provider so its IAccessible implementation returns S_OK or valid errors instead of failing.

Example fix

// before
var rect = accessible.Location; // MSAA call failed
// after
try { var rect = accessible.Location; }
catch (InvalidOperationException ex) when (ex.InnerException != null)
{
    log.Warn($"MSAA call failed: {ex.InnerException.Message}");
    accessible = ReacquireAccessible(element);
}
Defensive patterns

Strategy: try-catch

Try / catch

try
{
    var result = DoMsaaCall(accessible);
}
catch (InvalidOperationException ex) when (ex.InnerException is COMException ce)
{
    log.Warn($"MSAA op failed HRESULT=0x{ce.ErrorCode:X8}");
    accessible = ReacquireAccessible(element); // stale proxy; re-acquire
}

Prevention

When it happens

Trigger: Any proxied IAccessible call (property get, navigation, hit test) that returns a COM error not recognized/recoverable by HandleIAccessibleException — e.g. the underlying OLEACC/MSAA object returned DISP_E_MEMBERNOTFOUND, E_FAIL, or the accessible object was destroyed mid-call.

Common situations: Automating legacy Win32/MSAA applications whose accessible objects die during UI updates; mixed-technology UIs (WinForms/Win32) with unstable accessibility implementations; calls made while the target window is being torn down.

Related errors


AI-assisted analysis of dotnet/wpf@81131a70a4 (2026-09-14). Data as JSON: /api/errors/47af8d6e4803f814. Report an issue: GitHub.

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/UIAutomation/UIAutomationClientSideProviders/MS/Internal/AutomationProxies/Accessible.cs:533

                        throw;
                    }
                    return "";
                }
            }
            set
            {
                try
                {
                    _acc.set_accValue(_idChild, value);
                }
                catch (Exception e)
                {
                    if (HandleIAccessibleException(e))
                    {
                        throw;
                    }

                    throw new InvalidOperationException(SR.OperationCannotBePerformed, e);
                }
            }
        }

        // Return the Rect that bounds this element in screen coordinates
        internal Rect Location
        {
            get
            {
                NativeMethods.Win32Rect rcW32 = GetLocation(_acc, _idChild);
                return rcW32.ToRect(false);
            }
        }

        internal static Accessible GetFullAccessibleChildByIndex(Accessible accParent, int index)
        {
            int childCount = 0; 
            object[] accChildren = Accessible.GetAccessibleChildren(accParent.IAccessible, out childCount);

View on GitHub (pinned to 81131a70a4)