unable to open the base package + engine crash

[daanbeg]

Hi all,

We're trying to roll out jamovi 2.7.33.0 (x64) Desktop in a locked-down, centrally managed Windows enterprise environment (Windows 11 Enterprise, Microsoft Intune, standard non-admin users, Microsoft Defender with Attack Surface Reduction enabled). The cloud version is not an option for us, so it has to run locally. We've tried several approaches and each one fails in a different way — hoping someone has a working enterprise deployment method.

What we've tried:

MSIX package – installs to C:\Program Files\WindowsApps\, but standard users have no access to that folder, so the app won't launch. Error: "Windows cannot access the specified device, path, or file. You may not have the appropriate permissions." pointing at
...\WindowsApps\JamoviProject.…amovi...

EXE (.exe) installer, packaged as a Win32 app – installs cleanly to C:\Program Files\, but the application still fails to start.

Manual install directly on a technician's laptop – also fails to launch.

Portable executable repackaged – we copy jamovi to C:\jamovi\ and create a shortcut. Deployment succeeds, but when launching the .exe the app hangs on a white screen.

Defender / ASR findings:

An Attack Surface Reduction rule ("Block executable files from running unless they meet a prevalence, age, or trusted-list criterion") blocked RuntimeBroker.exe, related item C:\jamovi\bin\jamovi.exe. We added an ASR exclusion for C:\jamovi.
After that, the jamovi engine crashes. Application Error (Event ID 1000): faulting application jamovi-engine.exe version 0.0.0.0, faulting module ucrtbase.dll version 10.0.26100.8521, exception code 0xc0000409.
Launching jamovi-engine.exe manually returns: "Fatal error: unable to open the base package" — and there's no log indicating where it expects the base package to be.
Uninstalling also fails because of the same permission restrictions.

Questions:

• What is the recommended deployment method for jamovi in a managed, non-admin enterprise environment (per-machine install outside of WindowsApps)? Is an MSI or silent per-machine installer available?

• What does "unable to open the base package" mean, and which path/permissions does the engine need to find it?

• Are there known issues with Defender / ASR / exploit protection and the jamovi engine, and what exclusions or settings do you recommend?

• Has anyone successfully deployed jamovi via Intune to standard users? Any guidance would be hugely appreciated.

[jonathon]

Hi,

I wouldn't worry about jamovi-engine.exe ... that's not intended to be executed directly.

(Here's an LLM response)

Rather than guess at exclusions, the cleanest path is to let Defender tell you exactly what it's blocking and whitelist precisely those. Everything logs its own events:

1. ASR blocks → Event Viewer → Applications and Services Logs → Microsoft → Windows → Windows Defender → Operational

Event ID 1121 = blocked, 1122 = audited. Each entry gives the ASR rule GUID and the blocked file path.
I'd set the "Block executable files… (prevalence/age/trusted-list)" rule to Audit mode temporarily, then add ASR exclusions for the paths it reports (the jamovi install folder).
2. The engine crash (0xc0000409) → this is almost certainly an Exploit Protection mitigation, and it logs separately:

Microsoft → Windows → Security-Mitigations → UserMode (and KernelMode). Find the entry for jamovi-engine.exe at the crash timestamp — it names the exact mitigation that fired (likely ACG, CFG, EAF/IAF, or child-process creation).
Then set that mitigation to Off for the jamovi executables under per-app Exploit Protection (or exclude the folder from your exploit-protection baseline).

3. Quarantine check → same Windows Defender/Operational log, Event IDs 1116/1117 — confirms whether Defender pulled any bundled R DLL (which would also produce that crash). Restore + exclude if so.

Important: jamovi spawns several child processes and loads its R/Python DLLs lazily, so don't just launch it — open a data file and run a few analyses while in audit mode. That surfaces the full set of blocked paths and mitigations in one pass, rather than discovering them one crash at a time. Collect everything from a real session, then whitelist exactly those paths/rules/mitigations.

That'll give you a precise, minimal exclusion set tailored to your baseline instead of a broad guess. Happy to help interpret the events if you paste the 1121/1122 and Security-Mitigations entries.

Kind regards