Windows Desktop Integration#

Element Desktop on Windows faces two recurring categories of platform-specific issues: antivirus interference with file I/O at runtime, and intermittent signing/packaging failures during CI builds.

Antivirus Interference with Search Indexing#

Element Desktop uses Seshat (a Rust/SQLCipher-based native module, matrix-seshat) for full-text event indexing. The index is stored under the user's Electron userData path in an EventStore directory 1.

When endpoint security products (notably Cisco Secure Endpoint) scan these files during active read/write operations, they temporarily lock the files. This causes Seshat IPC calls to surface errors directly in the Element UI rather than retrying silently. 2

Current workaround: Disable search indexing in Element Settings → Security → Message Search. This avoids the file operations entirely, but sacrifices local search.

Upstream improvement tracked at: 3 — proposal to suppress search UI and display a clearer error when the index is broken/inaccessible, rather than failing noisily mid-search.

Relevant code#

• seshat.ts initEventIndex — Seshat initialization, ReindexError handling, and recovery logic. Errors here propagate to the renderer via sendError.
• seshat.ts deleteContents() — best-effort deletion of EventStore files; silently logs errors rather than throwing, so single-file lock failures don't crash the index.

The current error-handling at 4 forwards the raw error to the UI. File-locking errors from AV products arrive here as generic Node.js EBUSY/EPERM errors and are not retried.

Windows Build: Code Signing Failures#

Windows builds use signtool.exe (Windows SDK) invoked by electron-builder to sign Element.exe. The signing certificate is managed via SSL.com eSigner (EV Code Signing, issued by SSL.com EV Code Signing Intermediate CA RSA R2) with DigiCert as the timestamping authority. 5

The signing process is intermittently failing with ERR_ELECTRON_BUILDER_CANNOT_EXECUTE and a null exit code from signtool.exe. A maintainer confirmed this is a known SLA limitation of the SSL.com sandbox environment — not a code defect. 6

Configuration in apps/desktop/electron-builder.ts:

• Build targets: squirrel and msi (per-machine) 7
• Hash algorithm: sha256 8
• Certificate injected at build time via environment variables ED_SIGNTOOL_SUBJECT_NAME and ED_SIGNTOOL_THUMBPRINT 9
• The certificate subject name is also embedded in app metadata as electron_windows_cert_sn 10, used at runtime to compute a stable tray GUID

When you see this failure in CI: re-run the job — it is transient.

Windows Build: EPERM During Packaging#

A separate Windows-specific build failure is EPERM: operation not permitted when electron-builder attempts to rename dist/win-unpacked.tmp → dist/win-unpacked. 11

The root cause is a file lock held by node.exe on the .tmp directory during the extractArchive → prepareApplicationStageDirectory step of electron-builder v26.15.3. This can be exacerbated by antivirus scanning the directory at the same moment. 11

A maintainer noted that electron-builder forbids building inside system directories (only user/temp directories are allowed), and that errors originating from electron-builder itself should be reported upstream to electron-builder. 12

Workaround: Ensure builds run in a user-owned directory (not C:\Program Files\...), retry the build, and consider excluding the build output directory from real-time antivirus scanning on build machines.

Quick Reference#