[Problem/Bug]: WebView2 Runtime 153.0.4234.x performs a failed interactive logon (event 4625, SubStatus 0xC000006A "wrong password") as the current local user on every environment creation — can lock out Windows accounts on machines with account-lockout policies

Description

Starting with WebView2 Runtime 153.0.4234.x, every WebView2 environment creation (i.e. every new browser root process) triggers a Windows interactive logon attempt using the current local user's username with a wrong/invalid password. Each attempt records an Event 4625 on machines with failure auditing enabled and increments the bad-password count of the local account. On machines with an account lockout policy (e.g. "lock after 3 invalid logon attempts" — commonly enabled to mitigate RDP brute force), repeatedly launching any WebView2 app locks the current Windows user out — PIN and password login both stop working.

The behavior does not exist in WebView2 Runtime 144.0.3719.115: same host apps, same machine, same session — zero logon attempts.

Environment

• OS: Windows 10 Enterprise LTSC 2021 (19044), x64 — and Windows 11 Insider Build 26200.9457 (separate user report, see below)
• WebView2 Runtime (Evergreen, latest stable): 153.0.4234.48 — affected; 153.0.4234.32 — affected (independent report); 144.0.3719.115 / 144.0.3719.93 — not affected
• Windows session: local (non-domain) account, linked Microsoft account (MicrosoftAccount:target=SSO_POP_User / SSO_POP_Device present in Credential Manager)
• No system proxy configured on the machine

Repro steps

1. Enable failure auditing: auditpol /set /subcategory:{0CCE9215-69AE-11D9-BED3-505054503030} /failure:enable
2. Launch any WebView2 app (our product, a minimal test host, or a third-party WebView2 app) on a machine with Runtime 153.0.4234.48
3. Check the Security log → Event 4625 appears ~0.3–2 s after the root process is created, one event per environment creation
4. Downgrade the runtime by installing 144.0.3719.115 → same test produces zero 4625 events
5. Upgrade back to 153 → 4625 events return immediately (deterministic)

Verified with identical results for:

So it is independent of both the hosting framework and application code.

Observed Event 4625 (full fields)

Status:                     0xC000006D
SubStatus:                  0xC000006A   (wrong password)
FailureReason:              %%2313       (Unknown user name or bad password)
LogonType:                  2            (Interactive)
LogonProcessName:           Advapi
AuthenticationPackageName:  Negotiate
WorkstationName:            <local machine>
ProcessName:                C:\Program Files (x86)\Microsoft\EdgeWebView\Application\153.0.4234.48\msedgewebview2.exe  (browser root process)
IpAddress / IpPort:         - / -        (local, no network peer)
LmPackageName:              -
KeyLength:                  0
TargetUserName:             <current local account>

Timing: the event fires ~0.3–2 s after root msedgewebview2.exe process creation — before any page navigation completes — and exactly once per environment creation (no retries).

Impact

• Every app launch adds a bad-password failure. On machines with a lockout policy, repeatedly launching WebView2 apps locks the account; users experience simultaneous PIN and password lockout.
• Frequent-launch apps (terminal/utilities) are hit hardest; resident apps may only trigger once per boot.
• We believe most users don't notice because Event 4625 is not audited under default Windows configuration.
• We suspect (unconfirmed) the trigger requires a Microsoft-account-linked session (SSO_POP credentials present); we have not yet tested a session without a linked MSA.

Investigated and ruled out

• Not app code or hosting framework (see minimal-host repro above).
• Not HTTP integrated auth / Negotiate-vs-proxy-407: adding --auth-schemes=basic,digest --auth-server-allowlist= --auth-negotiate-delegate-allowlist= (confirmed present in the affected root process command line) does not prevent the 4625.
• Disabling the following features via --disable-features does not prevent it: msLoadOneAuthInBackground, msImplicitSignin, msImplicitSignInNetworkRetry, msOneAuthWAM, msProfileSignIn, msSeamlessWebToBrowserSignIn, msShowSignInIndicator, msWAMSovereigntySignIn, msWAMAdminModeSignIn, msAllowMSAPrtSSOForNonMSAProfile, msAutoToggleMSAPrtSSOForNonMSAProfile, msAutoToggleAADPrtSSOForNonAADProfile, msShowUXForAADPrtSSOForNonAADProfile, msEdgeOSAccountInfoSubstrate, msPrimaryOSAccountInfoCache, msEdgeOSAccountInfoManagerCache, msEdgeReauthAutoRefreshToken, msEdgePasskeysServiceReauth, msQuickAuthToBrowserSignIn, msForceBrowserSignIn, msEnableWebToBrowserSignIn, msEnableAADWebToBrowserSignIn, msEnableProfileAADAccountSSO, msMSNSignInLink, msSendSSODiagnostics, msEdgeSignInAccountPicker, AADSSO, AADWebSSOAllowed (tested individually, in groups, and all combined).
• WebView2 policies set under HKLM and HKCU Software\Policies\Microsoft\Edge\WebView2: ImplicitSignInEnabled=0, OnlyOnPremisesImplicitSigninEnabled=0, BrowserSignin=0, SyncDisabled=1 — does not prevent it.
• A NetLog capture shows no relevant network auth traffic after environment creation (only a config.edge.skype.com config fetch and the app's own local page), consistent with the logon attempt being non-HTTP.

Request

1. Please investigate the change between 144 and 153 that introduced this startup logon attempt, and fix it or provide an embedder-facing way (switch/policy/environment option) to disable it.
2. If a disable mechanism already exists, please let us know what it is.

Independent report: a user on Windows 11 Insider (Build 26200.9457, Runtime 153.0.4234.32) reported the same 4625 signature in our live support issue; their Windows account was locked out (Event 4740) by repeated WebView2 app launches.

Start with the 30-line minimal WebView2 host and reproduce under runtimes 144.0.3719.115 and 153.0.4234.x while checking Security Event 4625. Compare environment creation behavior and the listed sign-in settings; done means identifying the startup logon trigger and providing a fix or an embedder-facing way to disable it.