Stability and the blocklist

The thumbnail scanner instantiates plugins in rapid succession, which occasionally exposes a crash in a third-party plugin that would otherwise go unnoticed. VFxM is built to make that recoverable rather than disruptive.

What happens when a plugin crashes REAPER during a scan

1. Relaunch REAPER after the crash.
2. VFxM detects the interruption automatically and offers a Resume Crashed Scan prompt.
3. The specific plugin responsible is added to the stability blocklist, so it is skipped on this and future scans — the rest of your library still gets scanned.

Fixed in 1.2.2

Two parts of VFxM read and wrote this list, and they were using different locations. One of them therefore saw an empty blocklist, so Resume Crashed Scan could open the plugin that had just crashed REAPER and crash it again. Both now read the same file, and the resume skips what it is supposed to skip.

Managing the blocklist

Open Plugin Manager → Stability & Blocklist to:

• View which plugins are currently blocklisted and why.
• Manually unblock a specific plugin you believe is safe to retry.
• Click Clear Blocklist to reset all blocks at once.

The same list from the Thumbnail Manager

The Thumbnail Manager shows the blocklist too, so you do not have to leave a scan to deal with it. While anything is blocked it prints Blocked Plugins Active in red with the count, and a Manage Blocked button opens the list: an X beside each plugin unblocks that one, and Unblock All clears the lot — the same action as Clear Blocklist on this panel.

Nothing appears there while the blocklist is empty, which is why you may never have seen it. It is one list read from two places, not two lists.

Force-deactivated plugins are a different list

New in 1.2.3

Plugin Manager → Force Deactivated Plugins lists every plugin you have force-deactivated, beside the blocklist, with Reactivate per plugin and Reactivate All — the same two ways out the blocklist offers. Up to 1.2.2 this list was empty after every deactivate, because it read a record that was only written in a case that never happens on a normal machine; the way back existed (Status filter → Unlisted, right-click, Force Reactivate) but was written down nowhere. Reactivating also un-hides REAPER’s own cache entries.

The two lists are kept apart on purpose. The blocklist is the scanner’s crash record — a plugin that took REAPER down is not opened again. Force-deactivate is your decision. Merging them would mean Clear Blocklist silently un-hid every plugin you had chosen to hide, and a scanner crash would look like your choice.

Where the blocklist is kept

The list is a plain text file inside VFxM’s own data folder:

macOS

~/Library/Application Support/REAPER/Virtue/VFxM_ScanBlocklist.txt

Windows

%APPDATA%\REAPER\Virtue\VFxM_ScanBlocklist.txt

Before 1.2.2 this file, and the scanner’s queue and in-progress markers, sat loose at the top of REAPER’s resource folder. Updating moves them into Virtue/ for you, so a blocklist you built by crashing your way through a scan carries over rather than starting empty.

Why your project is never at risk

Your project file and track setup are never written to or modified by the scanning process. On the Mac from 1.2.5, the scan runs in a separate helper app outside REAPER and never puts a plugin on a REAPER track.