Summary
Microsoft Edge Stable 152.0.4191.53 can terminate with a native read-access violation during a CDP-controlled download after the same user-data directory is reused across browser launches.
The failure reproduces with a dependency-free Node.js harness that sends CDP messages directly; Playwright is not imported or executed. With the Edge binary, profile lifecycle, page, 5 MiB payload, download behavior, and CDP command sequence held constant, changing only the transport from --remote-debugging-pipe to --remote-debugging-port avoids the crash in the observed environment.
By default, the harness creates a dedicated new profile and serves the page and payload from a loopback HTTP server. It does not use an existing browser profile, extensions, authentication state, or an external website.
Environment
- Windows 11 Home x64, 10.0.26200 (build 26200)
- Microsoft Edge Stable 152.0.4191.53, x64
- Node.js 24.18.1 (the harness requires Node.js 22 or later)
- Initially observed through Playwright for Python 1.62.0, but Playwright is not required to reproduce
- Regression range: not established; the minimized matrix was validated against Edge Stable 152
Minimal reproduction
git clone https://github.com/ryo-whaletech/microsoft-edge-cdp-pipe-download-crash-repro.git
cd microsoft-edge-cdp-pipe-download-crash-repro
node repro.mjs --transport pipe --iterations 5 --download-behavior allow
On the affected system, the first launch normally succeeds and the second or third launch exits with 3221225477 (0xC0000005) before the download is finalized.
Transport control:
node repro.mjs --transport port --iterations 8 --download-behavior allow
The port control completed 8/8 profile reuses successfully. Every successful download was exactly 5 MiB and matched the generated SHA-256.
Isolation results
| Path |
Observed result |
| Edge + raw CDP pipe, no Playwright |
Native crash after 2–3 launches |
Edge + raw CDP pipe, allowAndName |
Same native crash |
| Edge + raw CDP port |
8/8 successful |
| Edge + Playwright attached over CDP port |
2/2 successful |
| Playwright-bundled Chromium 151 + persistent pipe context |
25/25 successful |
| Edge raw CDP pipe, headed and headless |
Both reproduce |
Calling download.save_as() is not required. The standalone harness reproduces by polling the generated download directory and the Edge process; it does not call a Playwright download API.
Native crash signature
Independent dumps from headed, headless, and standalone raw-CDP pipe runs resolved to the same instruction:
Exception: 0xC0000005 read access violation
Module: msedge.dll 152.0.4191.53
Module offset: 0x9D5C88B
Access address: near-null (0x18–0x21 across dumps; 0x1A in the validated run)
Expected behavior
The download should finalize and Edge should remain alive across repeated launches with the same profile, independently of the CDP transport.
Additional information
Repository, full control matrix, and sanitized evidence (revision 64b9baf42b7158053317a985d8a564724481203a):
https://github.com/ryo-whaletech/microsoft-edge-cdp-pipe-download-crash-repro/tree/64b9baf42b7158053317a985d8a564724481203a
Launching Edge with --remote-debugging-port and attaching over CDP is an effective mitigation. Could the Edge team investigate the native failure at msedge.dll + 0x9D5C88B and advise which component owns the pipe/profile-reuse interaction? Raw Crashpad dumps can be provided privately if useful.
Summary
Microsoft Edge Stable 152.0.4191.53 can terminate with a native read-access violation during a CDP-controlled download after the same user-data directory is reused across browser launches.
The failure reproduces with a dependency-free Node.js harness that sends CDP messages directly; Playwright is not imported or executed. With the Edge binary, profile lifecycle, page, 5 MiB payload, download behavior, and CDP command sequence held constant, changing only the transport from
--remote-debugging-pipeto--remote-debugging-portavoids the crash in the observed environment.By default, the harness creates a dedicated new profile and serves the page and payload from a loopback HTTP server. It does not use an existing browser profile, extensions, authentication state, or an external website.
Environment
Minimal reproduction
On the affected system, the first launch normally succeeds and the second or third launch exits with
3221225477(0xC0000005) before the download is finalized.Transport control:
The port control completed 8/8 profile reuses successfully. Every successful download was exactly 5 MiB and matched the generated SHA-256.
Isolation results
allowAndNameCalling
download.save_as()is not required. The standalone harness reproduces by polling the generated download directory and the Edge process; it does not call a Playwright download API.Native crash signature
Independent dumps from headed, headless, and standalone raw-CDP pipe runs resolved to the same instruction:
Expected behavior
The download should finalize and Edge should remain alive across repeated launches with the same profile, independently of the CDP transport.
Additional information
Repository, full control matrix, and sanitized evidence (revision
64b9baf42b7158053317a985d8a564724481203a):https://github.com/ryo-whaletech/microsoft-edge-cdp-pipe-download-crash-repro/tree/64b9baf42b7158053317a985d8a564724481203a
Launching Edge with
--remote-debugging-portand attaching over CDP is an effective mitigation. Could the Edge team investigate the native failure atmsedge.dll + 0x9D5C88Band advise which component owns the pipe/profile-reuse interaction? Raw Crashpad dumps can be provided privately if useful.