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
- Inspect InnerException for the COM HRESULT to identify the actual failure and address it.
- Catch InvalidOperationException around Accessible property/method use and retry after the UI settles.
- Re-acquire the AutomationElement/Accessible reference — the underlying MSAA object is likely stale.
- 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
- Inspect InnerException (COMException) for the HRESULT to diagnose the root cause
- Avoid touching accessible objects while the target window is being created/destroyed
- Add retry-with-delay around MSAA-heavy operations on dynamic UIs
- Prefer UIA (UIAutomationClient) over raw MSAA proxies on newer applications
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
- E_OUTOFMEMORY
- ElementNotAvailableException(e)
- RPC_E_SERVERFAULT/RPC_E_DISCONNECTED/RPC_E_UNAVAILABLE/DISP_E_BADINDEX/E_INTERFACEUNKNOWN/E_UNKNOWNWORDERROR/RPC_E_SYS_CALL_FAILED
- E_ACCESSDENIED
- E_INVALIDARG
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)