# [Bug] Browser main process crashes (0xC0000005 in Tabbit.dll) when tabbit-cli creates/closes task spaces — takes down the whole browser and any tabs (incl. DSH)

[vclike]

Environment

• Tabbit Browser: 1.9.22.0 (domestic stable, D:\Tabbit Browser\Application\Tabbit Browser.exe)
• OS: Windows 10/11 (build 26200, 10_0_26200)
• tabbit-cli: %LOCALAPPDATA%\Tabbit\LocalAgent\bin\tabbit-cli.exe
• Runtime Service: browser-runtime-service.mjs (node.exe) — spawned under TabbitDance dir of the browser installation
• Integration: driven via the official tabbit-browser DSH plugin (DeepSeek Harness), tabbit-cli nodejs --task '<name>'
• Reproduced 4× within ~30 min on 2026-08-19 (local 10:49, 10:59, 11:02, 11:16)

Summary

While driving the browser through tabbit-cli (creating task spaces / navigating / finishing tasks), the Browser main process crashes with an access violation inside Tabbit's own Tabbit.dll. Because the crash kills the main process, every open tab in the Browser is closed, including the DeepSeek Harness web UI tab that was running in the same browser — i.e. the automation host session is lost together with the browser. This makes the integration effectively unusable for interactive use.

Repro

Not 100% deterministic, but observed repeatedly during normal CLI use:

1. Launch Tabbit Browser (leave at least one normal tab open).
2. From a shell, invoke the CLI in a loop or sequence (observed with both creates and finishes):

$code = 'await page.goto("https://www.bing.com", {waitUntil: "domcontentloaded"}); return {url: page.url()};'
$code | & "$env:LOCALAPPDATA\Tabbit\LocalAgent\bin\tabbit-cli.exe" nodejs --task 'test-1'
& "$env:LOCALAPPDATA\Tabbit\LocalAgent\bin\tabbit-cli.exe" finish --task 'test-1'

3. Within seconds to a couple of minutes, the whole browser window disappears (main process gone); all tabs incl. the DSH tab are lost.

Notes on triggers we tested and excluded:

• NOT caused by number of task spaces created in a row (8 sequential new tasks: no crash).
• NOT caused by calling tabbit_browser_install({refresh:true}) repeatedly (pure reg/CIM detection; no effect).
• NOT caused by the system IME (flypy input method DLL was injected in all dumps but switching/keeping it made no difference; crash address maps inside Tabbit.dll, not the IME DLL).
• Crash occurs during Runtime Service ↔ Browser interaction (task space create/finish), i.e. around CDP Target.createTarget activity, but a stable-state run of the same operations succeeds. Feels like a timing/race defect inside the Runtime↔Browser channel.

Crash evidence

Windows Error Reporting / Crashpad

4 crash pairs, all identical signature. Dumps in
%LOCALAPPDATA%\Tabbit Browser\User Data\Crashpad\reports\:

time (local)	dump	exception code
10:49:20	dad12d21-…	0xC0000005
10:49:25	1f628a9f-…	0x0517A7ED
10:49:35	9bdeb7bb-…	0xC0000005
10:49:39	c5f69ca8-…	0x0517A7ED
10:49:42	259d694f-…	0xC0000005
10:49:44	a0104d4d-…	0x0517A7ED
10:59:23	1497f05b-…	0xC0000005
10:59:25	05157368-…	0x0517A7ED
11:02:18	b90db450-…	0xC0000005
11:02:30	752f1ece-…	0x0517A7ED
11:16:17	d7652367-…	0xC0000005
11:16:19	30f307c3-…	0x0517A7ED

(The pairs are the same crash recorded from two processes/threads — main + a secondary process.)

Minidump analysis (11:16:17 dump, d7652367-12d9-4db4-9d41-ddad50a951cb.dmp)

• Exception: 0xC0000005 (Access Violation), 2 exception parameters
• Faulting address: 0x00007FFF49F80283
• Faulting module: D:\Tabbit Browser\Application\1.9.22.0\Tabbit.dll (base 0x00007FFF42620000, size 0x11BA9000) — offset +0x7960283
• Not in Chromium (Tabbit Browser.exe / chrome_elf.dll) and not in any third-party DLL; it's inside Tabbit's own DLL.

Runtime receipts (persisted by the Runtime Service)

%LOCALAPPDATA%\Tabbit Browser\User Data\LocalAgent\Runtime\tasks\<taskId>\receipts\:

• First failure right before the 10:49 crash (task 0927696b):

  browserContext.newPage: Protocol error (Target.createTarget): Task-scoped CDP command could not be dispatched
  

• Right after a crash, all previously created task spaces vanish (Runtime Service restarts with the browser; task ids change, e.g. task-a6c0d7ca → task-ece2d203), confirming a full Runtime/browser restart.

Expected behavior

• tabbit-cli task create / navigate / finish should never take down the browser main process.
• If the Runtime↔Browser channel hits an internal error, the failure should be surfaced as a CLI error (like BROWSER_RUNTIME_UNAVAILABLE), without killing the browser and the user's other tabs.
• Crash in Tabbit.dll at offset 0x7960283 (access violation) — please add symbol/source info if available.

Impact

• Interactive use of DSH (or any automation host running inside a Tabbit tab) is destroyed on each crash — the host session dies with the browser.
• User-visible "browser restarts repeatedly" while the automation is running.

Dumps

Crashpad dumps available on request (12 files, ~1.4–2.3 MB each) at
%LOCALAPPDATA%\Tabbit Browser\User Data\Crashpad\reports\ — happy to attach a specific one.

Related

• The task-isolation/Target.createTarget dispatch path in the Runtime Service (runtime/src/browser-runtime-service.mjs) appears to be the interaction point that precedes the crash.

[chenmently]

Hi，we are so sorry for the inconvenience caused by this issue.

Could you please provide your Tabbit ID (found by navigating to tabbit://settings/passport ) so we can look into this further and investigate?