Chromium Screenshot Fails with DevToolsActivePort File Doesn’t Exist: Fix

DevToolsActivePort file doesn't exist means ChromeDriver did not find Chrome’s DevTools startup information where it expected it. It describes a failed startup handshake; it does not identify the underlying cause. Chrome may have crashed, been blocked from starting, or failed to create or access its profile directory. The most effective first steps are to capture ChromeDriver’s verbose log and Chrome’s stderr, then launch the same Chrome binary with the same arguments outside your test runner.

You may also see the message inside Chrome failed to start: crashed. Treat the missing port file as a symptom. Use the sequence below to find the earlier, more specific error.

1. Record the browser and driver actually in use

Before changing flags, establish which executables your run uses. A machine can have multiple Chrome or Chromium installations, and a test runner may select a different one from your interactive shell.

Read the Chrome binary path and complete launch command from the ChromeDriver log.
Record the Chrome or Chromium version for that binary.
Record the ChromeDriver version and executable path.
Check compatibility: Selenium’s Chrome documentation says the browser and ChromeDriver major versions must match. For Chrome releases beginning with M115, use the Chrome for Testing availability dashboard and release resources linked from the official ChromeDriver page.

A version mismatch is one possibility, not something proven by this error alone. Verify the actual paths and versions before replacing either executable. See Selenium’s Chrome documentation and the ChromeDriver version selection guide.

2. Turn on ChromeDriver and Chrome logging

The useful evidence is usually earlier in the log than the missing-port-file message. Enable ChromeDriver’s verbose logging and capture Chrome’s stderr so you can see whether Chrome crashed, rejected an argument, or encountered an environment problem.

ChromeDriver command line

chromedriver --verbose --log-path=/tmp/chromedriver.log

Run your Selenium client against that driver. Check the log for the browser binary path, complete command line, and first launch error. ChromeDriver’s --log-path behavior for capturing Chrome stderr differs on Windows because Chrome runs as a GUI application; consult the official logging guide for platform details.

Python with Selenium

This example enables verbose ChromeDriver logging and asks Chrome to write its own log. It assumes Selenium is installed and that a compatible ChromeDriver is available to Selenium’s driver manager or on the system path.

import os
from selenium import webdriver
from selenium.webdriver.chrome.service import Service

os.environ["CHROME_LOG_FILE"] = "/tmp/chrome.log"

service = Service(
    service_args=["--verbose"],
    log_output="/tmp/chromedriver.log",
)
options = webdriver.ChromeOptions()

try:
    driver = webdriver.Chrome(service=service, options=options)
    driver.get("https://example.com")
    print(driver.title)
finally:
    # If session creation failed, no driver was created.
    if "driver" in locals():
        driver.quit()

If your Selenium version does not accept one of these service arguments, check the API for the installed version and use its supported service logging options. Keep the logs from the failed run; the startup command in them is important for the next step.

3. Launch the same Chrome command directly

Copy the exact Chrome binary and arguments printed by ChromeDriver, then run them from a normal command prompt as the same operating-system user. Keep the same user-data directory and environment where possible. Do not substitute a hand-written command with different flags: the purpose is to reproduce the failing launch.

If Chrome fails directly too: investigate the browser installation, its arguments, profile path, and the first Chrome stderr error.
If Chrome starts directly: compare the test runner’s user identity, environment variables, working directory, permissions, temporary storage, and browser policies. IDEs, CI workers, scheduled jobs, services, and containers can have different settings from an interactive shell.

The ChromeDriver troubleshooting guide recommends comparing Chrome’s direct launch with its WebDriver launch. It also describes an all-users Chrome installer as a possible avenue for some background-service cases; apply that only when it fits your Windows environment.

4. Check the account and sandbox configuration on Linux

Prefer running Chrome under a regular, non-root user. ChromeDriver’s official troubleshooting guide identifies running Chrome as root on Linux as a common startup crash cause. The guide explicitly warns against --no-sandbox as a workaround: it is unsupported and highly discouraged. Do not add it as a generic fix. Correct the process user and sandbox setup for the environment instead.

If a container or CI image runs as root, inspect how the image starts the browser and whether it provides an appropriate non-root account. Use logs to establish the failure before changing container flags or resource settings.

5. Check the user-data directory and profile

ChromeDriver normally prepares a temporary user-data directory. If you set a profile explicitly, Chrome must be able to write to it, and another Chrome process must not be using it at the same time. ChromeDriver reads the DevTools port file from that directory; if Chrome cannot create the file, the handshake cannot complete.

Confirm the configured directory exists or can be created and is writable by the browser process.
Do not point automation at a live desktop profile or a profile another Chrome process is using.
Give each concurrent browser session its own user-data directory.
Check for stale Chrome processes that still hold the profile open.
If the log reports that a stale port file could not be removed, investigate whether the supplied profile is still attached to a running Chrome or Chromium process.

For a minimal Selenium reproduction, omit custom profile arguments first. If that works, add the profile configuration back and check its permissions and concurrency.

6. Isolate CI, service, and container differences

When Chrome launches locally but not in automation, compare the environments one difference at a time. Check the effective user, writable temporary directory, browser libraries, process limits, shared memory configuration, and the exact browser and driver installed in the image or worker.

A Selenium Docker issue report documents this error in one Linux container setup, but it does not establish Docker, shared memory, or any particular flag as the universal cause. Use the report as an example of where the symptom can occur, not as a recipe. Start with Chrome stderr and a minimal launch in the same container.

7. Check managed policy only when the evidence points there

On a managed machine, ask the administrator to inspect applicable Chrome policies if the logs indicate that remote debugging was blocked or the environment has restrictions on debugging. A 2023 community report describes one managed Windows setup associated with this error; it is an individual report, not evidence that enterprise policy is a usual cause.

8. Review headless and custom-profile combinations

Headless behavior and profile handling can depend on the specific Chrome and ChromeDriver versions. ChromeDriver’s release notes record a historical ChromeDriver 112 fix for a ChromeDriver 110 session issue involving --headless and --user-data-dir. That is evidence to check exact versions and arguments, not a current universal fix.

As a diagnostic, reproduce with the smallest argument set that represents your use case, then add headless mode and custom profile settings separately. Preserve the exact versions and launch command when reporting a version-specific issue.

Common errors and fixes

Evidence or situation	Likely area to investigate	Next step
Chrome stderr shows a crash before DevTools is ready	Browser installation, launch argument, missing runtime dependency, or environment	Resolve the first Chrome error; reproduce the same command directly.
Chrome and ChromeDriver major versions differ	Browser-driver compatibility	Install a compatible driver/browser pair and confirm the paths used by the run.
Failure occurs only in a service, IDE, CI worker, or container	Different user, permissions, environment, libraries, or temporary storage	Compare the failing environment with a direct launch under the same identity.
Custom profile is read-only or already in use	User-data directory access or concurrent sessions	Use a writable isolated profile per session; close stale processes.
Linux process runs Chrome as root	Unsupported startup configuration	Run as a regular user. Do not treat `--no-sandbox` as the standard remedy.
Managed Chrome log indicates debugging is blocked	Organization policy	Ask the administrator to inspect the applicable policy.
Only a headless plus custom-profile setup fails	Version-specific interaction or argument issue	Verify exact versions and test the options separately.

Performance, reliability, and cost considerations

Verbose logs and direct-launch checks add diagnostic work but do not require repeated full test runs: reduce the case to one browser session and preserve its logs. Once startup succeeds, use isolated profiles for parallel sessions to avoid profile contention. In CI, pin and record the browser and driver versions used by the job so a later image change can be compared with the known launch command.

This error itself does not establish a performance problem or identify a paid dependency. The cost of a fix depends on the environment you maintain. If your task only needs a website image or PDF and does not require controlling a local Chromium process, a screenshot API can avoid maintaining that browser startup path.

Or skip the browser setup

ScreenshotNeo is a website screenshot API and MCP server. A single GET request can return an image or PDF, so you do not need to launch ChromeDriver for a simple capture. See the ScreenshotNeo API documentation for request options.

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests

r = requests.get(
    "https://api.screenshotneo.com/v1/shot",
    params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"},
    timeout=90,
)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);
if (!res.ok) throw new Error(`ScreenshotNeo returned ${res.status}`);
await require('node:fs/promises').writeFile('shot.webp', Buffer.from(await res.arrayBuffer()));

ScreenshotNeo removes cookie banners, newsletter popups, and chat widgets before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The Free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. You can configure capture options such as full-page or element capture, viewport and device presets, wait conditions, custom CSS or JavaScript, and output format.

Create a free ScreenshotNeo account for 1,000 screenshots a month, with no card required.

FAQ

Does the missing port file prove ChromeDriver is outdated?

No. It reports that ChromeDriver did not obtain the expected DevTools startup information. Check the browser and driver versions, but use the logs to find the cause.

Should I always add `--no-sandbox`?

No. ChromeDriver’s official troubleshooting guidance says this workaround is unsupported and highly discouraged. Prefer a regular user and a correctly configured runtime.

Is Docker shared memory always the problem?

No. Container reports show the symptom can occur there, but the error alone does not identify shared memory or any other single container setting as the cause.

Can I use my normal Chrome profile for automation?

A profile in active use can cause contention. Use a writable, isolated profile for each concurrent session.