chromedriver.exe crashes with a stack overflow (0xC00000FD) about 35 seconds after loading a Best Buy product page

Component: ChromeDriver
OS: Windows 10 Home 22H2 (10.0.19045), x64
Chrome: 155.0.8059.80 (stable)
ChromeDriver: 155.0.8059.79 (stock download, unmodified)
Edge: 155.0.4283.60 with msedgedriver 155.0.4283.45 (also affected, so this looks like shared ChromeDriver code)

Summary

Load this page in a ChromeDriver session and leave it open:

https://www.bestbuy.com/product/apple-iphone-17-pro-max-256gb-silver-verizon/JCQ6HQTQ45

The page loads and the driver answers normally at first. Within about a minute of the navigation,
chromedriver.exe dies with exception 0xC00000FD (STATUS_STACK_OVERFLOW). The command in flight at that
moment gets no answer, the HTTP connection drops, and the browser is left running with no driver. Once
msedgedriver died before the navigation command had even returned.

No client action is needed to trigger it. The only commands sent after the navigation are
GET /session/{id}/title, every 5 seconds.

It reproduces on most loads, not every load, on this machine:

• 2026-10-15: four crashes (two chromedriver, two msedgedriver) in unattended Selenium runs.
• 2026-10-16: chromedriver crashed in 3 of 3 runs with a plain Selenium client.
• 2026-10-16: with the attached script and the stock drivers, both chromedriver and msedgedriver crashed
  on the same run. On other script runs one browser crashed and the other survived the 3 minutes.

How often it crashes follows how many third-party iframes the page loads (see "What the logs show").

Steps to reproduce

The attached script repro-chromedriver-stack-overflow.ps1 does this by itself and prints the result.
It needs only Windows, PowerShell 5.1, Chrome and chromedriver.exe. No Selenium or other client library
is used: the script speaks the W3C WebDriver protocol to the driver directly over HTTP.

apowershell -ExecutionPolicy Bypass -File .\repro-chromedriver-stack-overflow.ps1 -ChromeDriver C:\path\to\chromedriver.exe

Add -EdgeDriver C:\path\to\msedgedriver.exe to run Edge as well. The script:

1. Starts the driver with --verbose --log-path=<file> on a free port.
2. Creates a session with only --user-data-dir=<new empty folder> --no-first-run --no-default-browser-check.
3. Navigates to the product page above.
4. Sends GET /session/{id}/title every 5 seconds for up to 3 minutes.
5. Records whether the driver process exited and with what exit code, plus the tail of the verbose log.
6. Ends the session, or kills the browser if the driver died, and deletes the profile.

By hand: start chromedriver, create a session with any client, navigate to the page, then ask for the
title every few seconds. The driver process disappears within a minute.

Expected

The driver keeps answering commands for as long as the page is open.

Actual

• chromedriver.exe exits with 0xC00000FD, usually 30 to 60 seconds after the page loads.
• The title request in flight never gets an answer. The client sees the connection reset.
• The browser stays open, orphaned.
• Windows Error Reporting logs APPCRASH, faulting module chromedriver.exe 155.0.8059.79, exception
  code c00000fd.

What it is not

Each of these was tested separately:

• Not the client library. The first crashes came from Selenium 4.51 (.NET). The attached script
  uses no client library.
• Not the performance log. It crashes with and without goog:loggingPrefs {performance: ALL}.
• Not a modified driver. It crashes with the stock chromedriver.exe as downloaded.
• Not one browser. msedgedriver crashes the same way on the same page.

What the logs show

The page loads a large, variable number of ad "cookie sync" iframes (rubiconproject.com, onetag-sys.com,
pubmatic.com and others), most of them out of process. The driver auto-attaches to each one
(Target.attachedToTarget, then Page.enable, Page.addScriptToEvaluateOnNewDocument,
Runtime.evaluate and Target.setAutoAttach on the new session).

• Runs that crashed attached to about 280 to 300 iframe targets in under a minute.
• A Chrome run that survived the full 3 minutes attached to 24.
• Each crashing verbose log ends in the middle of this attach sequence for yet another ad iframe.
• The frames are nested only about 5 deep, so the recursion is not simply the frame tree.

A guess: the driver re-enters its event handling while it waits for command responses, and each newly
attached iframe adds another level, until a burst of a few hundred iframes runs out the stack.

Crash dumps

Full dumps (about 100 MB each) of both drivers were captured with Windows Error Reporting LocalDumps,
including from the stock drivers. They can be shared on request. In every chromedriver dump examined, the
faulting thread holds the same loop of 14 frames repeated about 188 times before the stack runs out. The
return addresses in the loop are identical from dump to dump, for example:

chromedriver+0x24dde7  chromedriver+0x24e076  chromedriver+0x24f0fa  chromedriver+0x24f852
chromedriver+0x251411  chromedriver+0x25175b  chromedriver+0x25188f  chromedriver+0x251f40
chromedriver+0x252ab9  chromedriver+0x257f7e  chromedriver+0x2681e7

Public symbols for chromedriver.exe were not available, so the function names are unknown.

Results on this machine

See repro-chromedriver-stack-overflow-results.txt and Chrome-driver-verbose.log, written by the
script next to itself.

Notes

• The page is a live retail page and its ads change from load to load. If one run does not crash, run
  it again. If the page stops crashing altogether, other product pages on the same site are worth
  trying.
• An ad blocker or network filter can cut the iframe count and hide the crash. Run without one.
• Found while regression testing the GPAL browser automation library.

Edge-driver-verbose.log
repro-chromedriver-stack-overflow.ps1.txt
repro-chromedriver-stack-overflow-results.txt