> ## Content Index > Fetch the complete content index at: https://izotoperx.net/llms.txt > Use this file to discover other available public pages before exploring further. # iZotope RX 12 Keeps Crashing or Won’t Open: Fixes - URL: https://izotoperx.net/izotope-rx-keeps-crashing-wont-open/ - Published: 2026-09-03T13:27:30.000Z - Updated: 2026-09-05T01:46:00.000Z - Description: Protect unsaved work first, then isolate the crash by timing: session restore, audio-device setup, plug-in scan, system compatibility or installation. - Author: Brandon Hayes - Tags: RX Problems, RX 12 If iZotope RX 12 keeps crashing or will not open, do not begin by deleting every cache or reinstalling the suite. Protect any recoverable work, note exactly when the failure happens, then test one variable at a time. A crash before the window appears points somewhere different from a crash while reopening yesterday's files, scanning a third-party plug-in or selecting an audio interface. After preserving work, check compatibility and choose the test that matches the failure point below. Start with a known-good local file, separate session recovery from plug-in scanning and audio-device setup, and consider reinstalling only when those tests have narrowed the problem. These are diagnostic branches, not a promise that one fix covers every crash. ## Start with the moment RX crashes | Failure point | Most useful first test | Branch to investigate | | -------------------------------------------- | ------------------------------------------------------------- | ------------------------------------------------------------- | | RX never shows a window | Check RX build, OS support and installation | Compatibility or installation; record any exact error message | | RX opens, then crashes while restoring files | Preserve session data first; then test without previous files | Session data or one damaged source | | RX fails during third-party plug-in scan | Note the last plug-in name and update/isolate it | Hosted VST3/AU/VST2 conflict | | RX crashes after choosing an interface | Disconnect optional hardware and test built-in output | Driver, device ownership or buffer setup | | Only one audio file triggers it | Open a known-good small WAV | File, codec, media path or session state | | Only a DAW project crashes | Test RX standalone and a blank host project | Host scan, plug-in format or project conflict | Write down the last visible action rather than “RX randomly crashes.” A repeatable trigger is useful evidence. It also prevents you from applying an unrelated fix: clearing RX session data will not repair an unsupported host, and rescanning plug-ins will not fix a damaged audio file. ## Protect session data before resetting anything RX stores temporary session data so edits can be undone and previous work can be recalled. The current [RX 12 Preferences manual](https://docs.izotope.com/rx12/en/preferences.html?ref=izotoperx.net) says these files may be large and recommends placing the Session Data folder on a drive with ample free space. Do not treat them as disposable cache files. iZotope's [Session Data support article](https://support.izotope.com/hc/en-us/articles/6658275507985-How-to-clear-RX-s-Session-Data-Folder?ref=izotoperx.net) explicitly warns that clearing the folder deletes in-progress or unsaved RX work. Before changing recovery settings or clearing anything, preserve the original audio and export recoverable edits under a new filename. Save an RX Document separately if you need the editing history. Locate the actual Session Data folder through Preferences > Misc; with RX closed, copy that folder to a separate location before experimenting. This extra copy preserves evidence but does not guarantee that damaged session data can be recovered. If RX cannot stay open long enough to locate the folder, and you do not already know its configured location, contact iZotope support before clearing files or dismissing recovery of irreplaceable work. Session locations can be customized. A guessed path from an older RX version may point at unrelated files or miss the actual data. ## Verify the exact RX 12 build and supported system Check the version before troubleshooting old advice. iZotope's [version-number guide](https://support.izotope.com/hc/en-us/articles/6658032333457-Finding-Your-Version-Number?ref=izotoperx.net) places the standalone RX version in the About screen—under Help on Windows and the iZotope RX menu on Mac. Record the complete number, not just “RX 12.” As checked on September 5, 2026, the current [RX Standard release notes](https://www.izotope.com/pages/release-notes/rx-standard?ref=izotoperx.net) list RX 12.0.0, released April 28, 2026\. They name macOS Sonoma 14.7, Sequoia 15.7 and Tahoe 26.4, and Windows 10 22H2 and Windows 11 24H2\. Intel Macs and Apple silicon are listed, with native and Rosetta support. Formats are 64-bit only. Those point releases and host versions are time-sensitive. Reopen the release notes before changing an operating system or DAW, especially if the crash began immediately after an update. “The operating system is generally supported” is weaker evidence than “this RX build, this point release, this architecture and this host version appear together in the current table.” Check the edition too: RX 12 Elements supplies plug-ins, without a standalone Audio Editor. Standard and Advanced include the Editor used in the steps below. The [RX 12 review](https://izotoperx.net/izotope-rx-12-review/) explains the available workflows if you are unsure which application should open. ## Try a clean launch without restoring yesterday's state RX 12 can reopen previous audio files with their edits, processing and undo histories. It can also reopen floating windows. That is convenient until the state being restored contains the trigger. After the backups above, if you can reach Preferences > Misc, temporarily disable **Reopen previous audio files when app starts** and **Reopen previous floating windows when app starts**. The [RX file-handling manual](https://docs.izotope.com/rx12/en/working-with-files.html?ref=izotoperx.net) explains that disabling file reopening changes shutdown behavior: RX asks what to do with unsaved tabs. Save them as RX Documents or cancel; do not discard needed edits. Then close RX normally, reopen it, and load a small known-good PCM WAV from a local drive. Do not start with the project that crashed. If the clean file works, add the previous conditions one by one: the original file, the original storage location, the external interface and any third-party hosted plug-in. For a restore or RX Connect loop that persists after work is preserved, iZotope's cleanup procedure starts in Preferences > Misc. Use the arrow beside Session Data Folder, then Show in Finder on Mac or Explore on Windows to reveal the exact directory. Close RX before copying or clearing its contents. The vendor procedure clears the files there, including the RX Connect folder. Only proceed when you have separate copies and accept losing the working session state. Reopen RX and test a known-good file. If the empty application still crashes, stop repeating the cleanup and test another branch. ## Nine steps to isolate an RX startup crash 1. **Protect recoverable work.** Preserve source files, export recoverable edits under a new name and save an RX Document when possible. Copy the identified Session Data folder with RX closed before changing recovery settings or clearing it. If irreplaceable data cannot be located, stop and ask support. 2. **Record the crash timing.** Note whether RX fails before the window appears, while restoring files, during plug-in scanning, after selecting an audio device or only when opening one file. 3. **Check the supported environment.** Compare the installed RX build, operating system, architecture and host version with current iZotope requirements and release notes. 4. **Test a clean launch.** After the backup, disable reopening previous files and floating windows in Preferences > Misc if reachable. Save unsaved tabs when closing, restart and test a small local PCM WAV. If Preferences is unreachable, use the hardware branch or contact support instead of guessing cache paths. 5. **Isolate session recovery.** If RX crashes while restoring previous work, back up what is recoverable and follow iZotope's session-data clearing procedure. 6. **Isolate third-party plug-ins.** If the crash occurs during scanning or module hosting, update and temporarily exclude suspect third-party plug-ins before rescanning. 7. **Test audio-device settings.** After saving work, close RX, disconnect optional audio interfaces and test a built-in output if available. Reconnect one interface for a separate test, refresh or select the device and compare a larger buffer. 8. **Reinstall the current build.** After preserving presets and project data, use the current official installer route for your license. Product Portal has an uninstall/reinstall workflow; iZotope subscriptions use Native Access. If installation permissions fail, involve the computer administrator. 9. **Collect evidence for support.** Record the exact RX and OS versions, repeatable trigger, file type, hardware, host, recent changes and crash report before contacting support. Make one change per launch and keep a short log. If you disconnect hardware, clear session state and reinstall at once, a successful launch teaches you nothing and the problem can return as soon as the original condition comes back. ## If RX crashes during the plug-in scan This section concerns third-party plug-ins hosted inside the RX Audio Editor, not RX plug-ins scanned by Logic, Pro Tools or another DAW. RX 12 supports VST3 on Windows and Mac and AU on Mac. VST2 support is conditional: the current manual limits it to Windows and Intel Mac or Apple silicon running through Rosetta. Watch the scan and note the last named plug-in before the crash. If the scan returns control, inspect the plug-in list for tags such as **\[Crashed\]** or **\[Failed\]**. The last name displayed is a lead to test, not proof of the culprit. Update that plug-in from its manufacturer, then temporarily exclude only the suspect component using the manufacturer's supported method. Preserve its settings and location, and close applications that use it first; shared plug-in components can affect other projects. Do not erase an entire system plug-in folder. The current Preferences manual says **Clear** removes the list for the selected format and **Rescan** can clear RX's blacklist after an update has resolved instability. Rescanning the same broken binary repeatedly is not a repair. iZotope's [third-party compatibility note](https://support.izotope.com/hc/en-us/articles/6658034822545-Third-Party-Compatibility-in-Ozone-and-RX-Applications?ref=izotoperx.net) says third-party plug-ins are not officially tested in RX. Its specific RX 7/8 examples are historical, so they do not establish an RX 12 defect or a current blacklist. If the issue is that RX modules are missing in your DAW rather than crashing the RX application, use the separate [RX plug-ins not showing guide](https://izotoperx.net/izotope-rx-plugins-not-showing/). ## If RX crashes after selecting an audio device Save work and close RX, disconnect optional USB or Thunderbolt audio interfaces, then relaunch and select built-in output if available. If you use an aggregate device, select a single physical or built-in device for this test rather than deleting the aggregate configuration. This is an isolation test, not a claim that your interface is defective. If RX becomes stable, reconnect one device, open Preferences > Audio and choose the Driver Type and Input/Output Device deliberately. Use **Device Refresh** to rescan newly connected hardware. Increase Buffer Size for the test: RX's manual says smaller buffers improve responsiveness and latency but require more CPU, while larger buffers reduce CPU cost at the price of latency. An offline repair editor does not usually need the smallest live-tracking buffer. If another application holds the device, save its work and close it before testing RX. RX's **Release when not in use** frees a device held by RX when RX playback stops; it cannot force another program to release that device. A larger buffer tests CPU headroom, not whether a missing device or incompatible driver has been repaired. Driver updates should come from the hardware manufacturer, and operating-system changes should be checked against both the interface and RX compatibility tables. ## If one file or one session crashes RX Open a short local WAV that you know works. If that file remains stable, make a copy of the problem source and test the copy from a simple local path. Do not overwrite the only original. A network mount, cloud-sync placeholder, damaged container or unusual codec can create a file-specific failure even when RX launches normally. If another trusted editor can open the source, export a separate uncompressed WAV test copy without deliberately resampling or downmixing. Keep the original untouched and record the source and export settings. A successful conversion helps isolate decoding or container behavior; it does not prove that damaged audio was recovered. If every file works until one restoration module is rendered, document the module, exact selection length and settings instead of treating it as a startup crash. RX Documents and ordinary exported audio are different recovery assets. Before clearing session state, export critical audio under a new name if possible. Use Save RX Document to retain the source, edits and view state; an RX Document opens in RX, while a WAV export can be checked in another player. The [RX 12 beginner workflow](https://izotoperx.net/izotope-rx-12-tutorial-beginners/) explains History, saving and export choices. ## Standalone RX crash vs DAW plug-in crash Test the two environments separately. If RX Audio Editor opens and processes a known-good file, but a DAW project crashes when loading an RX plug-in, the host's plug-in database, format, project state or compatibility becomes the primary branch. Create a blank host project and instantiate one current RX plug-in before opening the damaged session. If the blank project works, save a copy of the problem project and disable or remove instances one at a time. If every project fails, follow the host vendor's scan and cache procedure. Do not apply an old Logic, Pro Tools or Premiere cache path to a different host or current version without checking its documentation. If RX Connect launches the Editor into a loop, save the DAW project and source first. Then use iZotope's targeted Session Data/RX Connect cleanup procedure. For normal routing and handoff behavior, see the [RX Editor, plug-in and Connect workflow](https://izotoperx.net/rx-editor-plugins-connect-workflow/). ## When a preferences reset is reasonable If a crash started after a specific preference changed and Preferences still opens, record the current value and revert that one setting first. Note custom audio routing, plug-in folders, shortcuts and session locations before any broader reset. This keeps the test reversible and makes its result easier to explain. The RX 12 Preferences manual does not document a universal reset button or a startup safe-mode shortcut. For a full reset when the app will not stay open, ask iZotope support for the exact procedure for your build and OS. Do not delete guessed Library, AppData, Registry or Documents entries, or assume that holding Shift bypasses scanning in RX. Distinguish a missing or blank window from an application that actually exits. Record whether RX is still running and whether the problem began after a display change. Give support that observation before resetting preferences; a hidden window and a startup crash call for different tests. ## Reinstall RX only after the cause is narrowed Reinstalling replaces application and plug-in files; it may not remove damaged session state, an incompatible third-party plug-in or a driver conflict. Preserve presets, licence details, source files and any recoverable session data first. Note the current build so you can confirm the reinstall actually changed what was installed. For products managed there, iZotope's [Product Portal reinstall guide](https://support.izotope.com/hc/en-us/articles/8626171834525-Reinstalling-iZotope-Software-with-Product-Portal?ref=izotoperx.net) uses MY PRODUCTS > ALL and the product's trash icon to uninstall, then MY PRODUCTS > INSTALL/AUTHORIZE to reinstall. Its permissions troubleshooting recommends involving an administrator. The [current installer help](https://support.izotope.com/hc/en-us/articles/31410818687645-Can-t-download-or-install-How-to-fix-it?ref=izotoperx.net) provides standalone installer routes and directs iZotope subscription users to Native Access. Use the route appropriate to your license, then confirm the installed build and repeat the same clean-file test. Installation problems can also come from the user Documents folder. The official [Documents-folder troubleshooting article](https://support.izotope.com/hc/en-us/articles/6658046649361-Documents-folder-issues-with-iZotope-products?ref=izotoperx.net) connects installer errors with cloud redirection and read/write permissions. Its Mac menu examples include older macOS versions. Use it to identify the affected product folder and ask support for current steps if the menus differ; do not disable cloud storage or delete product folders without separately preserving their contents. If you are considering reinstalling because Elements lacks a standalone editor, first verify what your edition includes in the [RX Elements vs Standard vs Advanced comparison](https://izotoperx.net/izotope-rx-elements-vs-standard-vs-advanced/). Missing edition functionality is not a crash. ## What to collect before contacting iZotope support A useful report includes the complete RX version, edition, operating-system point release, CPU architecture, DAW and version if relevant, plug-in format, audio interface and driver version, source file format, available disk space, and the exact last action before the crash. Include whether a clean launch, known-good WAV and disconnected interface succeed. Attach the operating system's crash report and RX logs when support requests them. Name the suspect third-party plug-in and version rather than saying “the scan crashes.” List recent changes—RX update, OS update, new interface, new plug-in, moved session folder or cloud-sync change—and provide the shortest repeatable sequence. Stop local experiments if the crash affects irreplaceable session data, repeats after a clean supported reinstall, or appears to involve disk errors. Preserve copies and evidence. The [Fix iZotope RX hub](https://izotoperx.net/fix-izotope-rx/) separates startup failures from missing plug-ins, Connect problems and interface issues. ## Frequently asked questions ### Why does iZotope RX crash immediately on startup? Common branches include restoring damaged session state, an unsupported RX/OS combination, a third-party plug-in scan, an audio-device or driver conflict, and a damaged installation. The exact crash timing determines which branch to test first. ### Will clearing the RX Session Data folder delete work? Yes, it can delete in-progress or unsaved RX work. iZotope explicitly warns about that risk. Save or export what you can and copy recoverable session data before following the official clearing procedure. ### How do I stop RX reopening a crashing session? Preserve recoverable work and copy the identified Session Data folder first. If Preferences > Misc is reachable, disable reopening previous audio files and floating windows. Save unsaved tabs when closing, then restart with no files loaded. If you cannot locate irreplaceable session data, contact support before dismissing recovery or clearing files. ### Can a third-party plug-in crash RX Audio Editor? Yes. RX can host external plug-ins, and iZotope notes that they are not all officially tested. Update the suspect plug-in, isolate only that component, and rescan after the underlying issue has been addressed. ### Can an audio interface make RX crash? An interface, driver or device-ownership conflict can be a trigger. Test with optional hardware disconnected and built-in output, then reconnect one device and choose its driver, device and a conservative buffer deliberately. ### Should I delete RX preferences manually? Revert a known changed setting first if Preferences opens. For a full reset, obtain an exact current iZotope support procedure for your build and OS. The RX 12 Preferences manual does not document a universal reset button; do not delete guessed Library, AppData, Registry or Documents entries. ### Should I reinstall RX if it will not open? Reinstall after checking compatibility, session restore, plug-in scanning and audio hardware. A reinstall may not change corrupted session data or an incompatible external plug-in, so narrowing the trigger first saves time. ### What details should I send to iZotope support? Send the full RX and OS versions, edition, computer architecture, host and plug-in format, audio hardware and driver, source format, exact repeatable steps, recent changes, crash report and the results of clean-launch tests.