What happens when a VST3 misbehaves?
The project is built so third-party VST3 DSP and vendor GUI code are not deliberately loaded inside obs64.exe. That is the core crash-containment boundary.
The short answer
A VST3 plug-in is native code. Native code can crash, hang, misuse memory or call operating-system APIs. The safest practical host design is therefore not to pretend plug-ins are harmless, but to place them behind a process boundary.
What is isolated
- VST3 runtime: the third-party plug-in module runs in the helper process, not inside OBS.
- Vendor GUI: the plug-in's native editor is helper-owned rather than embedded as third-party code inside OBS.
- Scanning: VST3 candidates are probed outside OBS, with bounded child-process behavior.
- Recovery: helper health is monitored, and failures use bounded restart/backoff and state restoration.
What happens to audio during failure?
The realtime OBS filter is designed around a bounded wait for a valid processed result. If a valid wet block is not available in time, the filter keeps the original dry buffer instead of intentionally waiting forever for the VST3.
This matters for streaming: a broken effect should not become an excuse to put unbounded lifecycle, editor or disk work on OBS's realtime audio callback.
Can you promise OBS will never crash?
No responsible native-software project should make that absolute promise. Windows drivers, OBS itself, hardware faults, malicious code and operating-system failures exist outside this project's control.
The stronger and verifiable claim is this: third-party VST3 code is kept outside the OBS process by design. That materially changes the failure boundary compared with loading the same plug-in directly into obs64.exe.
Crash isolation is not a malware sandbox
The helper process runs with your Windows user permissions. A malicious VST3 could still access files, network resources or other APIs available to your account. Only load plug-ins from vendors you trust.
What the release pipeline checks
The public Windows release pipeline validates more than compilation. The current stable line includes protocol and lifecycle tests, scanner smoke tests, recovery/fault tests, OBS module compilation, compatibility loading against the supported OBS floor, portable-package validation, Smart Installer install/uninstall/reinstall checks and SHA-256 generation.
Automated CI still cannot prove every commercial plug-in on every machine. That is why real-machine plug-in compatibility evidence and reproducible user reports remain useful.
Unsigned Windows package
The current Windows package is not commercially Authenticode-signed. Windows may therefore show Unknown publisher or a SmartScreen reputation warning.
Do not disable Windows security globally. Download only from the project's official GitHub Releases page and compare the package against the published SHA256SUMS.txt when you want to verify integrity.