TL;DR
Ableton Live 12.2.7 crashes with EXCEPTION_ACCESS_VIOLATION consistently ~3 seconds after a project containing 3 instances of Serum
2 v2.1.4 finishes loading. The crash occurs after all VST3 processors have been instantiated, in what appears to be the plugin
editor / UI restore phase. Crash dump from 2026-06-07 named Serum2.vst3 and WebView2Loader.dll as the relevant modules, strongly
suggesting the crash is in Serum 2's WebView2-based editor during state restore.
A version of the same project with 2 Serum 2 instances (instead of 3) loads cleanly. Removing the saved Serum 2 controller state
from the .als XML did not prevent the crash.
I have all the relevant files (crash dumps, Ableton log excerpts, both the crashing project and the working older backup) bundled
and ready to send if it would help. Let me know what to email and where.
System
- OS: Windows 11 Pro 10.0.26200 (build 26200)
- CPU: AMD Ryzen 7 5800X (8 cores, 16 threads)
- RAM: 32 GB
- GPU: NVIDIA GeForce RTX 3080 (driver 32.0.15.9186)
- WebView2 Runtime: 149.0.4022.69 (was 148.0.3967.96 on 2026-06-07, same crash on both)
- Audio interface: Universal Audio UAD Solo
DAW
- Host: Ableton Live 12 Suite 12.2.7 (Build 2025-11-03_828a8aa814)
- Plugin format used: VST3
- Plugin path: C:\Program Files\Common Files\VST3\Serum2.vst3
Serum 2
- Version: 2.1.4
- Source: Official installer from xferrecords.com
- Reinstalled: Yes (clean uninstall + reinstall performed on 2026-06-07). Did not fix the issue.
- Preset DB rebuilt: Yes (Documents\Xfer\Serum 2 Presets\System\presets.db renamed; Serum 2 rebuilt from scratch on 2026-06-17).
Did not fix the issue.
Other plugins in the affected project (all VST3)
These all loaded successfully before the crash:
- Neural DSP Archetype Cory Wong v2.0.1 (x2 instances)
- Neural DSP Parallax X v1.0.0
- iZotope Iris 2 v2.02 (x2 instances)
- Native Instruments Massive X v1.7.1
- IK Multimedia TR5 Quad Limiter v5.10.4
- Various Ableton stock devices (EQ Eight, Limiter, etc.)
Nothing else uses WebView2 in this project.
What happens
- Open Ableton Live 12.2.7
- File → Open Live Set → black bag.als (3 Serum 2 instances saved into the project)
- Project finishes loading, UI becomes visible, transport ready, plugin chains visible
- Within ~3 seconds, Live crashes hard with EXCEPTION_ACCESS_VIOLATION. No grace, no save prompt, just disappears.
The crash is after all VST3 plugin processors have been instantiated. Ableton's log shows the last successful operation a few
seconds before the exception:
2026-06-17T22:06:45.595229: info: VST3: Going to restore: Serum 2
2026-06-17T22:06:45.670796: info: VST3: plugin processor successfully loaded: Xfer Records 'Serum 2' v2.1.4 (cid:
{56534558-6673-5073-6572-756D20320000})
2026-06-17T22:06:45.679862: info: VST3: Found 1 program change parameters for plugin Serum 2
2026-06-17T22:06:45.718767: info: VST3: Restored: Serum 2
…
[2 more Serum 2 instances restored the same way]
…
2026-06-17T22:06:47.407482: info: VST3: plugin processor successfully loaded: IK Multimedia 'TR5 Quad Limiter' v5.10.4
2026-06-17T22:06:49.554186: error: Windows Exception: EXCEPTION_ACCESS_VIOLATION
The crash fires 2.14 seconds after the last plugin processor finishes loading. This delay strongly suggests the exception is in
plugin editor (GUI) re-creation, not in audio processor initialization.
Crash dump analysis (from 2026-06-07 session)
When I had this crash on 2026-06-07, the minidump named two passenger modules:
- Serum2.vst3 (Xfer Records, Serum 2 v2.1.4)
- WebView2Loader.dll (Microsoft Edge WebView2 Runtime)
This pointed at a JUCE + Microsoft Edge WebView2 + Live race condition during plugin editor re-creation when the project restores
Serum 2 instances that had their editor windows open at save time. There's a known class of issues in this area, WebView2
teardown/init can hit access violations if it doesn't sequence correctly with the host's window lifecycle.
All four .dmp files in my bundle reproduce the same access-violation signature.
Triggering pattern
Project state matters. Here's what I found by inspecting Ableton's automatic project backups for black bag.als:
- Backup 2026-06-16 22:16:11 — 2 Serum 2 instances, plus 1 Iris and 1 Massive X. Loads cleanly.
- Backup 2026-06-16 22:17:58 — 3 Serum 2 instances, 2 Iris, no Massive X, 1 extra MIDI track. Crashes.
- Backup 2026-06-17 16:43:06 — 3 Serum 2 instances, same content as above plus small edits. Crashes.
- Current black bag.als — 3 Serum 2 instances plus jazz drum kits, extra drum break loops, more MIDI. Crashes.
The 2-instance backup opens fine. The 3-instance backup crashes the same way. The third Serum 2 instance was added between 22:16:11
and 22:17:58 on Jun 16. It looks like a count or interaction threshold around 3 simultaneous Serum 2 instances triggers the crash,
but I can't confirm whether it's the count specifically or something about that particular instance's saved state.
What I tried that did NOT fix it
- Clean reinstall of Serum 2 v2.1.4 (2026-06-07), same crash on next project load.
- Uninstalled Apple Bonjour Service (dnssd.dll was a passenger module in the dump on 2026-06-07), same crash. Bonjour was not the
root cause. - WebView2 Runtime auto-updated from 148.0.3967.96 to 149.0.4022.69 between sessions, same crash on the newer runtime. Not
version-specific to a single WebView2 build. - Rebuilt Serum 2's preset database (renamed Documents\Xfer\Serum 2 Presets\System\presets.db, let Serum 2 rebuild on next launch)
on 2026-06-17, same crash. - Stripped the saved ControllerState block from each Serum 2 instance in the .als XML (preserved ProcessorState, removed only the
GUI/controller state that gets passed to the IEditController on restore). The project still crashed in the same place. This tells
me the crash is not triggered solely by the saved controller-state being applied; it appears to fire even when Serum 2 has no saved
UI state to restore.
The fact that #5 did not help is the most surprising data point. It suggests the WebView2 / editor crash happens during normal
plugin instantiation after restore, not specifically from re-applying the saved controller state, when 3 instances are present.
What I haven't tried yet
- Rolling WebView2 Runtime back to a much older major version (148 didn't help; deeper rollback would mean a non-evergreen /
fixed-version runtime which Microsoft doesn't officially expose). - Disabling all other plugins in the project to isolate whether the trigger involves another plugin alongside the 3rd Serum 2
instance. - Loading the project on a different machine to rule out anything local.
Happy to run anything else you want. I have minidumps from multiple separate crashes today and from 2026-06-07, plus both project
files (the crashing 3-instance version and the working 2-instance backup), the Ableton crash log, and the Ableton verbose Log.txt
excerpt covering the crash window.
Files I have ready to send
If you'd like any of these for diagnosis, just tell me where to email them:
- 4 Ableton minidumps (.dmp), 3 from today's session, 1 from 2026-06-07. All show the same EXCEPTION_ACCESS_VIOLATION pattern.
- Ableton verbose Log.txt excerpt covering the crash window (~530 lines).
- The crashing .als project file (contains my in-progress music, happy to share with Xfer support, would prefer not to post it
publicly). - The working older backup .als (2 Serum 2 instances, otherwise similar content).
- Full system info / dxdiag / Live's audio settings if helpful.
Thanks for taking a look. Serum 2 sounds incredible; I'd love to get back to using it.
