Hey there, let's tackle this frustrating crash problem you're dealing with. The --no-sandbox and --disable-dev-shm-usage flags are solid initial fixes, but it sounds like we need to dig deeper. Here are some targeted steps to resolve the "unable to determine loading status from crashed tab" error:

1. Upgrade Your Chrome Version First #

Chrome 99 is quite an outdated release—many stability bugs related to tab crashes and session management have been fixed in newer versions. Even a minor jump to the next stable build (like 100.x or later) could resolve the issue outright. Old Chrome versions often have unpatched memory leaks or compatibility issues with modern web content that trigger crashes.

2. Tweak Headless Mode Parameters (If Applicable) #

If you're running Chrome in headless mode, the older --headless flag has known stability issues in version 99. Switch to the newer headless implementation with:

options.add_argument("--headless=new")

Additionally, add these flags to eliminate GPU-related crashes (common in old headless setups):

options.add_argument("--disable-gpu")
options.add_argument("--disable-software-rasterizer")

3. Add More Resource & Stability Flags #

Beyond the flags you already use, these can help mitigate crashes in resource-constrained environments:

• --disable-setuid-sandbox: Works alongside --no-sandbox to disable additional sandboxing layers that can cause crashes in non-standard environments (like containers).
• --memory-pressure-off: Forces Chrome to ignore system memory pressure warnings, preventing it from killing tabs aggressively.
• --max_old_space_size=4096: Increases the V8 engine's memory limit (set to 4096MB here; adjust based on your available RAM).
• --disable-extensions --disable-plugins: Disables all extensions and plugins, which are frequent culprits of unexpected crashes.

4. Replace time.sleep() with Explicit Waits #

Relying on fixed time.sleep() values is unreliable—pages load at different speeds, and waiting too long can waste resources while waiting too short can trigger race conditions. Use explicit waits (e.g., with Selenium's WebDriverWait) to wait for specific elements or states before proceeding:

from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC
from selenium.webdriver.common.by import By

# Wait up to 10 seconds for a critical element to load
WebDriverWait(driver, 10).until(
    EC.presence_of_element_located((By.ID, "critical-element-id"))
)

This is far more stable than arbitrary sleep timers.

5. Reduce Page Resource Load #

If the target page has heavy content (large images, complex JS, multiple iframes), try disabling non-essential resources to test if that's causing the crash:

options.add_argument("--blink-settings=imagesEnabled=false")  # Disable image loading
options.add_argument("--disable-javascript")  # Test if JS is triggering crashes (temporary)

If the crash stops when these are disabled, you'll know the issue is tied to specific page content.

6. Enable Detailed Logging to Diagnose the Root Cause #

To get precise insight into what's triggering the crash, enable Chrome's verbose logging:

options.add_argument("--enable-logging")
options.add_argument("--v=1")  # Adjust verbosity level (1-5)

The logs will output to your console or a specified file. Look for entries like [FATAL] or [ERROR] right before the crash—these will point you to the exact component (e.g., renderer process, GPU, sandbox) failing.

Start with upgrading Chrome, then work through the steps above—most users find that combining a version update with adjusted headless flags and explicit waits resolves this crash issue.

内容的提问来源于stack exchange，提问作者Sainath Reddy