[Problem/Bug]: Standalone Microsoft Edge 156.0.4314.58 (stable) still triggers a failed interactive logon (4625, 0xC000006A) per new headless browser root process and can lock a local Windows account (4740); WebView2 156 fix does not cover it

The report identifies standalone headless msedge.exe on Windows 11 25H2 and compares it with WebView2 issue #5722 and Chromium issue 541310282. Start by reviewing those reports and the Edge 156 WebView2 fix details; reproduce whether launching a fresh profile causes the 4625 event. Done means establishing whether standalone Edge is affected and documenting a supported mitigation or the fix status.

Summary

This is a follow-up to #5722, which was closed as fixed with WebView2 156 preview ("Fixed failed Windows interactive logon attempt for the current local user" — 156.0.4314.8 release notes).

On Windows 11 25H2 with standalone Microsoft Edge 156.0.4314.58 (stable) and WebView2 Runtime 156.0.4314.58, an automated headless-Edge workload still produces Event 4625 (failed interactive logon, 0xC000006A, wrong password) — one per new msedge.exe root process — and the accumulated failures actually locked the local Windows account (Event 4740). After the lockout, lock-screen unlock failed with 0xC0000234; the fingerprint sensor matched the finger (Biometrics 1004) but sign-in was refused. Sign-in worked again only after the Windows account-lockout interval had elapsed.

The failing process is msedge.exe (standalone Edge browser), not msedgewebview2.exe, so the WebView2 156 preview fix does not appear to cover this path.

Environment

• OS: Windows 11 25H2, build 26200.9457
• Microsoft Edge: 156.0.4314.58 (stable; installed before the incident, EdgeUpdate shows no later update)
• WebView2 Runtime: 156.0.4314.58 (Evergreen stable)
• Account: local, non-domain; the machine uses an account-lockout policy (10 failed attempts / 10-minute window / 10-minute duration)
• Trigger: automated headless-Edge workload (Remotion via Puppeteer) configured to use msedge.exe; every render/still starts a new headless msedge.exe root process with a fresh temporary --user-data-dir. No user interaction and no intentional password entry.

Observed 4625 fields (identical signature for all events)

Status:                    0xC000006D
SubStatus:                 0xC000006A
FailureReason:             %%2313
LogonType:                 2
LogonProcessName:          Advapi
AuthenticationPackageName: Negotiate
ProcessName:               C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe
IpAddress / IpPort:        - / -
TargetUserName:            <current local user>
SubjectUserName:           <current local user>
WorkstationName:           <local machine>

Observed pattern

• Each new msedge.exe browser root process produced exactly one 4625 before navigation, with a distinct PID and no network peer.
• Two bursts of 10 × 4625 within roughly 5 minutes produced two 4740 lockouts.
• After the account was locked, Windows+L unlock attempts failed with Winlogon status 1909 (ERROR_ACCOUNT_LOCKED_OUT) / Hello error 0xC0000234, although fingerprint recognition succeeded (Biometrics 1004).
• Sign-in succeeded again exactly when the 10-minute lockout interval elapsed.

Why this looks like the same regression

• Identical 4625 field signature to #5722 and the Chromium report (LogonType 2, Advapi, Negotiate, 0xC000006A, no network source), matching the CheckBlankPasswordWithPrefs / LogonUser hypothesis discussed in the thread (chromium issue 541310282).
• One attempt per new browser root process with a fresh profile, before navigation; no retries. A long automated task launches many such processes in a few minutes, which is enough to reach a lockout threshold.
• Other commenters in #5722 already reported standalone msedge.exe failures on Edge 154/155; this report adds Edge 156.0.4314.58 stable plus the resulting 4740 and the user-visible lock-screen failure.

Workaround / mitigation used locally

• Raised the Windows account-lockout threshold (impact mitigation only; the 4625 events continue).
• From #5722: --disable-features=AutofillAiWalletPrivatePasses is reported to suppress the 4625 in WebView2 hosts; it has not been verified here for standalone Edge.

Request

1. Does the WebView2 156 fix cover standalone (msedge.exe) as well, or only the WebView2 runtime? If not, is a fix planned and for which Edge version?
2. Is there a supported way to suppress this for standalone headless Edge (launch flag, policy, or feature flag), and is --disable-features=AutofillAiWalletPrivatePasses valid for it?
3. Does the trigger depend on creating a new profile/user-data-dir? Would reusing a persistent profile avoid one logon attempt per launch in automation scenarios?
4. If useful, I can provide redacted 4625/4740 event XML in a follow-up comment.

(Account and machine names, exact timestamps, and locale/time zone have been omitted.)