[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
@prija-microsoft ci sta già lavorando.
Dal 6/11/2026.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Bug
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Ambito
- backend
Direzione di ricerca
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.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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 headlessmsedge.exeroot 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.exebrowser 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/LogonUserhypothesis 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.exefailures 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=AutofillAiWalletPrivatePassesis reported to suppress the 4625 in WebView2 hosts; it has not been verified here for standalone Edge.
Request
- 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? - Is there a supported way to suppress this for standalone headless Edge (launch flag, policy, or feature flag), and is
--disable-features=AutofillAiWalletPrivatePassesvalid for it? - 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?
- 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.)
- Lingua principale
- PowerShell
- Stelle
- 526
- Fork
- 70
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di MicrosoftEdge/WebView2Feedback
-
bug
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
MicrosoftEdge/WebView2Feedback#5749 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 25/100
MicrosoftEdge/WebView2Feedback#5798 ·
-
[Problem/Bug]: Runtime 157 suppresses <input type="file"> in Outlook add-in task panes ("top-level window size is smaller than the minimum required size (400x300)")Forse già presa @ambikakunnath l’ha presa 1 giorno fa. Apertaregression
MicrosoftEdge/WebView2Feedback#5797 · 1 assegnatario ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
MicrosoftEdge/WebView2Feedback#5796 ·
-
[Problem/Bug]: PDF viewer fails on inline page dictionaries in /Kids; standalone WPF reproductionApertabug
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
MicrosoftEdge/WebView2Feedback#5795 · 2 commenti ·
Tutte le issue di MicrosoftEdge/WebView2Feedback
Issue simili
-
`Time.at(t, in: nil)` returns UTC instead of the local time (or the time zone of `t`), unlike CRubyAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
PageParameters.hashCode is inconsistent with equals for named parameters in a different orderAperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
bug implicit-state
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 4 giorni