**Report ID:** Not available — see note at the end of this post.

> *Note: This is a native crash (access violation inside `xul.dll`). It produces no entry in Zotero's JavaScript error log, so "Report Errors" has nothing to submit for it — the dialog reports only JS errors logged since startup. I've included the exact crash signature and the debug output leading up to the crash instead.*

Hi — Zotero 10.0.2 crashes reproducibly about 20 seconds after launch, while the startup full-text indexing/sync is running. The fault is always in `xul.dll` at the same offset. It still happens with **every plugin removed**, and it stops completely when I disable the syncing of full-text content.

### Environment

- Zotero 10.0.2 (64-bit), Windows 11 Home (zh-CN), build 26200
- Data directory on a local disk (`C:\Users\...\Zotero`) — not a network share
- Library: 2,064 items, 856 attachments, 485 annotations, 68 collections
- 579 PDF/EPUB attachments, a large proportion of them **Chinese-language PDFs**

### Crash signature

| Field | Value |
|---|---|
| Application | `zotero.exe` 10.0.2.0 |
| Faulting module | **`xul.dll` 140.15.0.2510** |
| Exception code | **`0xc0000005`** (access violation) |
| Fault offset | **`0x4399ff9`** |
| Time from launch to crash | 18–30 seconds |

### Steps to reproduce

1. Ensure `extensions.zotero.sync.fulltext.enabled` is `true` (the default).
2. Start Zotero.
3. Wait ~20 seconds, while the startup full-text index/sync runs.
4. Zotero crashes with the signature above. No error message is shown — the process simply disappears.

### What I have ruled out

- **Plugins** — I renamed the profile's entire `extensions` folder so that all 15 plugins were disabled. It **still crashed**, at a different offset (`0x43b9aa1`), so the crash site moves with the configuration rather than being caused by one plugin.
- **General sync** — with `extensions.zotero.sync.autoSync = false` and the sync username cleared, it still crashed (`0x0d08259`, while loading CSL styles).
- **Database corruption** — `PRAGMA integrity_check` returns `ok` (verified twice, on a copy of `zotero.sqlite`).
- **Hardware** — the CPU passed a 30-minute OCCT Extreme AVX2 stress test with **0 errors**; there are no WHEA hardware errors in the Windows event log and no BSODs in the past 7 days.

### What stops the crash

Setting a single preference:

```js
// user.js in the profile directory
user_pref("extensions.zotero.sync.fulltext.enabled", false);
```

With that one change, Zotero has been running for over an hour — **including through the entire 30-minute 100 % CPU stress test** — with zero crashes. Re-enabling it brings the crash back immediately and reliably.

### Exact crash location in the log

Captured with `-ZoteroDebugText` redirected to a file. **Note that file sync completes normally first — the crash is in the full-text *upload* step that follows:**

```
zotero(3): Done with file sync for 我的文库
zotero(3): Done with file syncing
zotero(3): Starting full-text syncing
zotero(3): Starting full-text sync for 我的文库
zotero(3): Library version hasn't changed -- skipping full-text download
zotero(3): Uploading full-text content for 我的文库
zotero(4): SELECT itemID, indexedChars, totalChars, indexedPages, totalPages
FROM fulltextItems FI JOIN items I USING (itemID) WHERE libraryID=? ...
zotero(3): Getting full-text content from cache file for item 1/ZDLJTKBX
zotero(3): Getting contents of C:\...\storage\ZDLJTKBX\.zotero-ft-cache
... (repeats for many items) ...
zotero(3): HTTP POST "[{"key":"ZDLJTKBX","content":"General Electric Aviation
Cincinnati, Ohio\nIntelligent Engine Systems\nHPT Clearance Co...
zotero(3): POST body gzipped from 513541 to 268274; 48% savings
zotero(3): {
"Content-Encoding": "gzip"
"Content-Type": "application/json"
"If-Unmodified-Since-Version": "15978"
<-- process dies here; nothing further is logged
```

So the crash occurs while uploading full-text content to `api.zotero.org` (a 513 KB POST body, gzipped to 268 KB).

A separate, **benign** WebDAV error also appears in the logs but is unrelated — it is non-fatal and file sync completes right after it:

```
zotero(1): Error: DAV:href '/' does not begin with path '/zotero/'
purgeOrphanedStorageFiles@chrome://zotero/content/xpcom/storage/webdav.js:1373:15
zotero(3): No local changes made during file sync
zotero(3): Done with file sync for 我的文库
```

I can supply the full debug output if that's useful — it's ~1 MB.

### Possible connection to CJK full-text indexing

Zotero 10 introduced CJK full-text indexing (the `fulltextContentCJK` table), and this library contains a large number of Chinese-language PDFs. The crash consistently occurs while full-text index/sync work is in progress, which is why `sync.fulltext.enabled` appears to be the trigger.

### This also happens on Zotero 9 — with the same timing pattern

This is **not new in 10.x**. On the same machine, with the same library, Zotero 9.0.4 and 9.0.6 produced **~86 crash reports** in Windows Error Reporting between 2026-07-15 and 2026-09-13 — all in `xul.dll`, with exception `0xc0000005` (plus a few `0x80000003`).

Most importantly, the **timing signature is identical**: the process dies seconds after launch.

| Version | Faulting module | Crashes analysed | Time from launch → crash |
|---|---|---|---|
| Zotero **9.0.6** | `xul.dll` 140.10.0.2910 | 36 | min **3 s**, median **13 s** |
| Zotero **10.0.2** | `xul.dll` 140.15.0.2510 | 12 | min **4 s**, median **17 s** |

Across both versions, **35 of 50 crashes occurred within one minute of launch**, and 70–80 % within 30 seconds.

*(Timing is derived from the "Faulting application start time" field of the Windows Application Error events still present in the event log — a subset of the total WER reports, which had rolled over.)*

*(Fault offsets are not directly comparable between the two versions, since `xul.dll` is a different build in each — 140.10.0.2910 vs 140.15.0.2510. The comparison here is of the crash **pattern**, not of the specific code location.)*

So whatever this is, it predates Zotero 10 — it may have been introduced with the Zotero 9 line or exposed by something specific to this library. The `sync.fulltext.enabled` finding above is the first concrete lead I've been able to establish.

### Additional notes

- I have **not** yet tested with a fresh profile, and I'm happy to do so if that would help narrow it down.
- The library contains a large number of Chinese-language PDFs, and Zotero 10 introduced CJK full-text indexing — in case that's relevant to the full-text sync path.

Thanks — happy to run any additional diagnostics you'd like.