Scrivener installer won’t launch on Windows 11 — Process Monitor shows TEMP access errors despite admin rights

Hi everyone,

I wanted to share (and hopefully resolve) a very stubborn issue I’ve been facing trying to install Scrivener for Windows 3.1.6 on Windows 11.
The installer consistently crashes before showing any UI, and I’ve been going through multiple rounds of testing to figure out what’s happening under the hood.

:puzzle_piece: The symptom

When I run Scrivener-installer.exe, even as Administrator, it closes instantly or doesn’t even open.

Windows Event Viewer logs:

Event name: APPCRASH
Faulting application: Scrivener-installer.exe
Exception code: c0000005
Faulting module: <random .tmp file>

The dump points to InstallBuilder’s temporary .tmp module — which never fully loads.

:brain: What I’ve already tested

Antivirus / Security software

Disabled ESET and Malwarebytes (my main AV tools).

Still crashes immediately.

Permissions and ACLs

I discovered that my %TEMP% folder had an incorrect group assignment, breaking permission inheritance.

I repaired it so that both Owner and Group are now:

BUILTIN\Administrators

Even after that fix, the installer still doesn’t launch.

Clean TEMP directory / new environment

Tried launching from a new folder:

mkdir C:\TempInstall
$env:TEMP = “C:\TempInstall”
Start-Process -FilePath “Scrivener-installer.exe” -Verb RunAs

→ same crash.

Event Viewer correlation

At the exact time of the crash, I noticed SRUJet “Access denied” warnings (unrelated, but interesting).

Nothing else shows up that would point to malware or blocked processes.

ProcMon trace

Before crashing, InstallBuilder tries to create several .installbuilder_installer_* folders and hits thousands of BUFFER OVERFLOW / NAME NOT FOUND events in %TEMP%.

Then it dies with an access violation (c0000005).

:puzzle_piece: What I suspect

At this point, I’m down to three possibilities:

The installer binary is corrupt or fails signature validation.

Some runtime (Visual C++ / DEP / SmartScreen policy) is breaking the stub.

There’s still a deeper permission or security context issue specific to my Windows profile.

:toolbox: System details

Windows 11 Pro 23H2

Admin privileges confirmed

System context (possible interference)

ESET Internet Security (active service)

Malwarebytes Premium (real-time)

RogueKiller RTP / Adlice Diag

GlassWire network monitor

Multiple ASUS background services (ProArt, Optimization, etc.)

AMD Software (overlay, noise suppression)

Paragon HFS+/APFS drivers

I’ve already tried running the installer after disabling some of these tools, I don’t know if any of them is injecting into the InstallBuilder process before it initializes.

No sandboxing / virtualization active

Previous Scrivener install on an older user account in the same system worked perfectly

:puzzle_piece: What I’d like to know

Is there a way to run the installer with verbose logging (–debug or similar)?

Does Scrivener’s InstallBuilder stub depend on any Visual C++ redistributable that must be preinstalled?

Has anyone seen the installer crash before even creating its temporary folder?

I’ve attached all relevant details so far (event logs, ACL fixes, context).
Any insight or advanced logging switch I could try would be hugely appreciated — I’m determined to get Scrivener running again on this machine.

Thanks in advance!
—Edgar

1 Like

Any particular reason why you’re still on 23H2? 25H2 was released last month and 24H2 was before that. I know 25H2 has a horrible Start Menu that harks back to Windows 10 with it’s million and ten useless icons, but you appear to know your way around a computer and can still have 25H2 and revert the awful-ugly Start Menu through a tool.

TL;DR: If the Scrivener Windows installer (Scrivener-installer.exe,v3.1.6.0) crashes on your machine with an “Application Error” / exception code 0xC0000005 right as it’s finishing extracting files, skip straight to the Workaround section below — installing via the Microsoft Store worked for me with no changes needed.

Symptom

Running Scrivener-installer.exe (even “Run as administrator”) closes abruptly partway through setup. Windows Event Viewer shows two related entries under Windows Logs > Application:

  • Event 1000, Application Error — faulting application Scrivener-installer.exe (3.1.6.0), faulting module a temp file like BRxxxx.tmp, exception code 0xc0000005 (access violation)

  • Event 1001, Windows Error Reporting — same process, APPCRASH

What I ruled out

Before digging further, I tested (and ruled out) the usual suspects:

  • No third-party antivirus installed (Windows Defender only, no custom exclusions needed)

  • TEMP/TMP environment variables point to a valid, writable folder

  • A completely fresh re-download of the installer from the official site — same crash

  • Temporarily switching the Windows system locale (for non-Unicode programs) to English (US) + reboot — same crash

So this isn’t a corrupted download, a permissions issue, or a regional-settings quirk on the user’s end.

What’s actually happening (for the curious/technical)

Running the installer under Process Monitor (Sysinternals) shows it successfully extracting all of its internal UI image resources into a temp folder (.installbuilder\.tmp_<pid>\) — icons, slideshow images, message-box icons, etc., all with no errors.

The last resource it extracts has an odd name unlike all the others: x01image_small.png (note the stray x01 prefix — no other resource has anything like it). Immediately after that one file is written and closed successfully, Windows launches WerFault.exe and the installer exits with status -1073741819 (i.e. 0xC0000005) — matching the Event Viewer entries above.

This points to a bug in how this specific installer build handles that one resource (possibly related to the recent Qt 6.4.3 framework upgrade, or a compatibility issue with newer Windows 11 builds), rather than anything on the user’s system.

Workaround: install via Microsoft Store

Installing Scrivener through the Microsoft Store app worked without any issue and runs identically to the direct-download version. This is a workaround, not a fix for the .exe installer itself — but it gets you up and running immediately.

Status

I’ve reported this (including the Process Monitor findings above) to Literature & Latte support, so hopefully it gets fixed upstream. If you hit the exact same crash, feel free to reply here with your Windows build number and whether the Microsoft Store workaround works for you too — might help narrow down whether this affects everyone on 3.1.6.0 or just certain Windows versions.

1 Like

Thanks for posting your findings, and the workaround.

…might help narrow down whether this affects everyone on 3.1.6.0 or just certain Windows versions.

Fortunately it is certainly not the former! That’s been out for a little under a year now, and I bet you’d have a hard time finding any threads other than installation crashing threads around here, if we’d let it sit around for a year with nobody being able to install it.

To the contrary whatever it is seems very rare. It might be a Windows version as you say, but I would strongly suspect it takes even more than that—perhaps a particular anti-virus software with a certain configuration, for an example (and such an example could explain why the “store” would work as it may give it more leeway than random downloaded .exes).

2 Likes

I’m permanently on Windows Insider builds, currently known as the Experimental Channel, version 26H2, build 26300.8772. That’s never been a hassle for Scrivener updates.

1 Like

(What I mention below is well outside the normal troubleshooting routine, but if you know some programming, it may be helpful. If you are not a programmer, then this will probably not make much sense.)

You seem to know your way around Windows, so here is something you can try for getting more information about the crash, but to be useful, you need to know a little about how 64-bit instructions are structured so you know where to start looking.

  1. Download WinDbg (Windows debugger) from here and run the installer.
  2. Right-click on the WinDbg 64-bit edition and select Run as Administrator.
  3. From the debugger’s menu, select File / Open Executable… and navigate to the Scrivener installer (Scrivener-installer_3.1.6.exe).
  4. The installer should load and stop execution in the debugger at the very beginning of the program run.
  5. Press F5 (Go) to continue execution.
  6. I suspect that the installer will crash and the debugger will halt execution at the crash point.
  7. Here is where 64-bit ABI knowledge is needed: dump the registers, particularly RCX, RDX, R8 and R9 which contain the parameters to the function that crashed. If the register values look like pointer addresses, checking memory pointed to by those register values may provide clues to what is going wrong.

I know 99.9% of forum readers won’t care about this, but it is a method often used to begin tracking down vague crash report causes.

4 Likes