What causes "UnauthorizedAccessException" in dotnet/wpf?

Do not attempt to read password field values; assert on other signals (field presence, masked length) instead

dotnet/wpf · warning · UnauthorizedAccessException

UnauthorizedAccessException

Error message

UnauthorizedAccessException

What it means

The value pattern's GetValue on MSAA-backed elements deliberately throws UnauthorizedAccessException when the underlying accessible object reports IsPassword, so automation clients cannot read password content. This is an intentional privacy/security guard, not an environment failure.

Solutions

Do not attempt to read password field values; assert on other signals (field presence, masked length) instead
Check the IsPassword property / IsOffscreen style indicators before retrieving Value and skip password fields
Inject test credentials via configuration and verify behavior, not stored values
Catch UnauthorizedAccessException around Value retrieval and treat password fields as unreadable by design

Example fix

// before
var text = valuePattern.Current.Value;
// after
string text = null;
if (element.TryGetCurrentPattern(ValuePattern.Pattern, out var p))
{
    try { text = ((ValuePattern)p).Current.Value; }
    catch (UnauthorizedAccessException) { text = "<password field: value withheld>"; }
}

Defensive patterns

Strategy: try-catch

Validate before calling

bool isPassword = element.Current.HelpText?.Contains("password") == true || /* check app-specific marker */ false;

Try / catch

try { value = valuePattern.Current.Value; }
catch (UnauthorizedAccessException) { value = "<withheld: password field>"; }

Prevention

Never read or log password field values in automation
Skip elements flagged as password when snapshotting forms
Assert credentials via behavior, not stored values

When it happens

Trigger: Calling ValuePattern.Value (which invokes the virtual GetValue) on a password edit control (ES_PASSWORD style / accessible role reporting a password field).

Common situations: Test frameworks trying to log or assert the content of a password box; automation scripts scraping login dialogs; attempting to snapshot all field values in a form including credentials.

Understand the failure class

Background: Permission denied / not authorized / 403 Forbidden: access-control rejections when the caller lacks the required role, grant, or ownership — this error's family across 18 libraries.

Authentication and authorization failures — expired tokens, bad credentials, and missing scopes.

Related errors

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

Appendix: source

Thrown at src/Microsoft.DotNet.Wpf/src/UIAutomation/UIAutomationClientSideProviders/MS/Internal/AutomationProxies/MSAANativeProvider.cs:962

            }
            else if (idProp == AutomationElement.HasKeyboardFocusProperty)
            {
                return _acc.IsFocused;
            }
            else if (idProp == AutomationElement.IsOffscreenProperty)
            {
                return _acc.IsOffScreen;
            }
            return null;
        }

        // overridable method used by value pattern to retrieve the value.
        protected virtual string GetValue()
        {
            // if this is a password edit control then throw an exception
            if (_acc.IsPassword)
            {
                throw new UnauthorizedAccessException();
            }

            return _acc.Value;
        }

        // overridable method used by value pattern to set the value.
        protected virtual void SetValue(string val)
        {
            _acc.Value = val;
        }

        #endregion Protected Methods

        //------------------------------------------------------
        //
        //  Private Methods
        //
        //------------------------------------------------------

View on GitHub (pinned to 81131a70a4)